Practical Use 1 - Incrementing values by amounts less than one

If you move a sprite across a screen, you can only provide integers to the display hardware. It needs to know which pixel to turn on, there aren’t half pixels. This means if you’re incrementing a sprite’s position and doing it one pixel per frame is too fast, you need to somehow make it only get moved every other frame, or every fourth frame, etc so it appears to move slower, you can’t do anything else.

This is incredibly easy to do with fixed point maths. an 8.8 fixed number has 256 fractional parts before you count up one whole number. So store your sprite’s x and y position as regular integer values, but store a velocity vector as fixed point values and then increment the velocity vector by 1, 16, 32 or whatever you want. When updating your sprite’s position on screen, convert the velocity vector back to a regular integer and add it to the position.

When storing screen co-ordinates, store those as regular unsigned integers. Our 8.8 version might not have enough range to handle the whole screen. The X and Y size of the ZX Spectrum’s display for example is greater than 128 pixels. Also be clear whether you are using unsigned or signed values.

This is a benefit of making our own number system, we can choose to manually increment the bits and what those bits represent depending on what is most optimal. We’re not adding the 8.8 fixed representation of “1” - that would add 256. Instead we’re just adding a literal 1 to the 16 bits which is the same as adding 1/256th. We could convert “1/256” to its fixed point value and add that on, but understanding the numbers we’re working with should make it obvious why adding a literal “1” does the same. Remember the computer doesn’t care what these bits represent.

So now your sprites can use velocity vectors to have more interesting movement. No more jerky or floaty jump mechanics!