Shifting & subpixels

A nice little trick when programming J2ME stuff is making use of bit shifting. In java this is done by using the “>>” and “<<" operators. Basically, when you perform a bit shift the ones and zeros that make up the binary value in a integer is moved either to the left or to the right, and the leftmost or the rightmost bit is set to zero (depending on which way you move). The practical use of this is that you can do divide or multiply operations by the power of two at a much less cost in processing speed then if you would do it with the conventional * and / operators.

As an example, the expression "x<<1" gives the same result as "x*2". "x<<2" gives the result of "x*4", "x<<3" is "x*8" and so on. In the same fashion, "x>>1″ gives the same result as “x/2″, “x>>2″ is “x/4″ and so on.

Java has a special bytecode instruction for shifting, so even if the Java JVM has to interpret it’s bytecode (unlike native languages like C that translates shifting directly to a processor instruction), it’s much faster.

Note: Shifting negative numbers can give you unexpected results. For example -10>>8 should give you the result 0 but it returns -1. (big thanks to Ed for pointing this out)
Update: Robbin Chaddock pointed out that bit shifting does not round up it’s results in the same way that regular division does. “The division operator rounds towards 0, where-as the right shift operator (>>) rounds towards negative infinity. Consequently for uneven negative integers x>>1 is not equal to x/2.”

So, what’s really so good about this you might ask yourself? In J2ME you don’t have access to floating point data types (well, you do on platforms that support CLDC 1.1, but I still don’t recommend using floating point stuff..it’s slow!). If you for example want to have sprites that move and accelerate smoothly you need a way to describe their positions on a sub-pixel level. That means that the sprite can actually be placed between two pixel positions. This would be easy if you could describe the positions using decimals (like x=2.6 y=4.67), but we can only use integers in J2ME. However, similar functionality can be achieved by having a number of sub-pixel steps (for example 8 position steps per pixel). When drawn, the position on screen is translated by dividing the position with the amount of sub-pixel steps. Sounds wierd? It’s actually a quite simple concept.

Lets say you want to animate an accelerating car, moving from one side of the screen to the other. If the screen is 128 pixels wide and you want to have 8 “sub-pixel” positions per pixel, the x position of the right side of the screen would be 128 * 8 = 1024. The car is moved by adding a speed variable to it’s x position each frame. The acceleration is done by increasing the speed variable by 1 each frame. And when you draw your car, you calculate the “real” screen position by dividing the x position with 8. And that could be done fast and easy by simply shifting x two times to the left, screen_x = x>>3. Since the car is actually moving on a sub-pixel level, the animation you get to see will seem smooth and nice. If you want it even smoother, just use a higher amount of “sub-pixel” steps per pixel!