thanks for the quick replies. gfoot, the problem i'm having with 2.5 is that when i go to actually "move" the object, i need to enter a number of pixels. e.g. if i try to move 0.5 pixels every frame it will not move at all. i had come up with a solution to that but then realized it was incomplete.
There are a few solutions to it, both involving support for fractional pixel movement. You can either go with
floating point or with
fixed point calculations.
Floating point is basically what you're doing now, but instead have (x, y) and (vx, vy) be floats. They'll need to be converted to integers whenever you draw them, though.
Using floating point values usually implies a bit of a performance hit: floating point calculations are slower than integer calculations (so x += vx will be more expensive if x and vx are floats),
and you'll need to do a float->int conversion each frame.
Now, this may be perfectly acceptable for your case; if there's not a whole many of objects moving around on screen, you will barely notice the hit, and the processor probably still has lots of CPU cycles to burn per frame. In addition, the method is fairly intuitive, so you could very well go with it.
The alternative is using
fixed point. Here's a short explanation for the people who've never heard of it before. It may appear to be more complicated, because this time the numbers involved will be in a different
representation than the decimal one we're all used to, but in essence it's also very simple and it's faster than floating point calculations.
With fixed point arithmetic, we'll treat a 32-bit or 16-bit integer like it contains both an
integer ("whole number") and a
fractional part. You can choose the size of the integer, and the bit sizes of the different parts based on how big you need your numbers to be, and how precise you need to fractions to be, but fixed point integers will typically look like this:
Code:
+-----------+------------+
| I | F |
+-----------+------------+
16 bits 16 bits
8 bits 8 bits
In this diagram, the top part I of your integer will contain the integer part of the number, and the lower part F will contain the fractional part of the integer.
For example, using one 16-bit integer word, you could encode the number 2.5 as 2 in the I part, and 128 in the F part.
Why 128? Because the F part can contain 256 different numbers (0-255). Think of "256" as "1". 128 is exactly half of this: 2 * 0.5 = 1, and 2 * 128 = 256. The math works out.
In effect, the number you'll get is 640:
Code:
+-----------+------------+
| 2 | 128 |
+-----------+------------+
2 * 256 = 512
128 * 1 = 128
-------------- +
640
What good is such a number? Well, it turns out you can actually do arithmetic with these numbers.
For example, if we need to calculate 2.5 + 2.5, we can just add our fixed point representation of 2.5 (640) to itself, giving: 640 + 640 = 1280.
And what do you know? Our fixed point representation of 5.0, is 5 * 256 + 0 = also 1280!
The number scheme is consistent: we just have scaled up all numbers by a factor of 256 (or even 32768 if you use a 32-bit word to store your numbers).
This is Good News(tm), because:
- Addition is cheap! It's just integer addition, every processor can do that with its eyes closed.
- Remember that we also still need to convert these fixed point numbers to "regular integers", to be fed into drawing routines as screen coordinates. It turns out that is very cheap as well: we simply need to take the top part (I) of the fixed point number, and we're done! That can be done with division by 256: 1280 / 256 = 5. Division is not very cheap, but we can take another operation that is cheap instead, and is exactly equivalent: bit shifting. By shifting our fixed point integer 8 bits to the right, the fractional part "falls off", and we're left with only the integer part. In C, you'd write that as:
Fixed point numbers do not have as large a range as floating point numbers, though. Floating point numbers can easily contain numbers like a gajillion trillion, fixed point numbers cannot, so you'll need to be aware of the highest number you'll want to store, and choose your fixed point accordingly.
I hope this helps without confusing
.
