Moving pixel-by-pixel with Bitmap Editor

[tuzmusic]

I used the Bitmap Editor to render my graphic, but the graphic moves by its full width, 16px, for every memory address (x-value, sort of) it traverses. I finally figured out it's because each "x value" is not 1 pixel but 16.

Therefore, to move (16384, 11111111) right by one pixel is not (16385, 11111111) but rather (16384, 01111111) AND (16385, 10000000).

Implementing something like this would be damn complicated (especially with no left- and right-shift operators) but not impossible. Lots of multiplying and dividing by powers of 2, etc.

Has anyone implemented this before? I'd use it if it exists, but if not I may just settle for my jumpy bitmap movement.

[WBahn]

For left shift you can simply add the value to itself (equivalent to multiplying by two). But the Hack has no simple way of effecting a right shift. It would not be hard to incorporate it into the CPU design, but of course neither the provided CPU Emulator nor the VM Emulator would support it.

Settling for a jumpy movement seems perfectly reasonable. As does accepting the huge speed hit that moving pixel by pixel will probably entail. The goal should be to learn what you can from whatever you do; you can't expect much in the way of performance from such a simple processor.

[ivant]

I think Mark Armbrust (cadet1620) had implemented a relatively fast right shift using some trickery as part of one of his floating point library. Check out this thread for more details. The code is linked in the first post.

[WBahn]

His Right Shift routine implements a right rotation by left rotating 31 times (since his float is 32 bits) and dealing appropriately with the sign bit.

So it is not efficient at all (but probably about as efficient as it can get as Jack code on the basic Hack architecture). It would probably be a good routine to implement as an assembly-level subroutine -- that might improve the performance significantly and the floating point routines probably call it enough to make it worthwhile. If you weren't interested in using (or extending) the VM Emulator you could add a VM command to support it and a Jack operator to invoke it.