“Your mother's so fat, inflationary theory got a lot more complicated once the physicists took her into account.”
Sometimes you'll find that you need more precision than straight-up integers allow you in Axe.
Here's an example: Say you're designing a Zelda-like action RPG involving enemies that move around and fight you. You wouldn't want it to be too hard even with many enemies converging on your poor little character, so you decide to make the enemies move half as fast as your character does. The obvious solution would be to make your character move two pixels a frame and the enemies one, but what if there's an object moving half the speed of that—say, a turtle sitting in the middle of the road? You could change your character to have him move four pixels a frame, the enemies two, and the turtle one, but an 8×8 sprite moving four pixels at a time looks very choppy. A better solution would be to make the turtle half a pixel per frame, and ways to do that will be our topic for this lesson.
You know that variables in Axe are supposed to be integers between 0 and 65,535, but remember that data is whatever you make of it. The only limit is yourself that they hold two bytes. One thing you can do is inflate your coordinates by 256, treating only the top eight bits (called the most significant byte) as the integer value and the lower eight bits (least significant byte) as a fraction. This format is also called 8.8 fixed point, since eight bits form the integer part and eight form the fractional part of a number. In bits, the number 10.5 would look like this in 8.8 format:
| Most significant byte | Least significant byte | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 | 1⁄2 | 1⁄4 | 1⁄8 | 1⁄16 | 1⁄32 | 1⁄64 | 1⁄128 | 1⁄256 |
| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
You don't have to know exactly what the numbers look like; that table above is just there to confuse you. Just know that the 8.8 format effectively treats a two-byte integer as a number between 0 and (almost) 256 that can have a fractional part that's any multiple of 1⁄256. Ten and a half, 2.75, and 0.00390625 are all numbers that can be expressed in valid 8.8 fixed point; 9.99 is not, because 0.99 is not a multiple of 1⁄256.
Now notice that if it weren't in fixed point format, the number in the table above would be 2688, or 10.5 times 256. This is the idea behind inflating numbers: by multiplying a number by some constant inflation value (usually 256, which forms 8.8 fixed point), you can add "fractions" to it.
Here's an example of the idea in action.
The /256 in the Pt-On( statement restores our inflated values back to a more sane integer that the drawing routine can use. Since ever 256 units represents a single pixel the way we're inflating the numbers, adding 128 to X in each pass of the loop (every frame) moves the character right one pixel every two frames. Similarly, adding 86 to Y simulates adding about a third of a pixel each pass. Here's what it looks like, broken down step by step:
| X | Y | X/256 | Y/256 | |
|---|---|---|---|---|
| Initial | 0 | 0 | 0 | 0 |
| Frame 1 | 128 | 86 | 0 | 0 |
| Frame 2 | 256 | 172 | 1 | 0 |
| Frame 3 | 384 | 258 | 1 | 1 |
| Frame 4 | 512 | 344 | 2 | 1 |
| ... | ... | ... | ... | ... |
Notice how X changes once every other frame and Y about once every third; that's the effect we're after. When the program runs, it looks like the square's moving half a pixel right and a third of a pixel down every frame (or at least like it's moving down at two-thirds the speed it's moving right):
It's more obvious when there are other objects moving at full speed for reference, but we'll leave that up to you.
You might be wondering why 256 is usually used for inflation, as opposed to 2, 10, 100, or some other number that you might be more comfortable working with. Well, there are several reasons.
Of course, it's not always appropriate for everything. If you have a scrolling map that contains more than 256 pixels across or down, for example, the 256 full integers you're allowed by 8.8 fixed-point (inflation by 256) might not be enough. In that case, you could use 2 as a factor since operations with two are also very optimized, but you'd sacrifice the precision.
| « | Table of contents | » |
|---|