Yeah I' having the same problem!

I dont get where you pull these extremly large numbers out of :O
256? 768? 15265? What does it all mean bazzle?

Yah... Too many numbers xD

Not really

Think of it this way: let's say you want to move to the right 1.5 pixels per frame. But you can't have half pixels - so instead, you double your X coordinate, and divide by two. Make an improper fraction of sorts, because Axe can easily store those, instead of a decimal, which is harder. Change it so that instead of moving 1.5 pixels per frame, you use 2x inflation and move 3 pixels, but divide your X coordinate by 2 each frame. Axe rounds all division operations, so it's going to round the fraction to the nearest pixel.

That probably made no sense. Example:

.Move character 1.5 pixels per frame to the right
.when the User presses the right key

0->X
[CHARACTER_SPRITE]->Pic1

Repeat getkey(15)

.If they press right
If getkey(3)
X+3->X
.Add 3/2, not 1.5
.They look like the same - however, since 3/2 always returns
.1 in Axe (because it rounds down), we had 3, and divide
.by 2 later on in the code.
End

ClrDraw
Pt-On(X/2,0,Pic1)
Dispgraph

End

^^In this example, I'm only using 2x inflation. 256x inflation means you can move 1/256 of a pixel each frame.

Did that make sense?

I'm assuming so because it's 2^8...

Exactly. So the calculator makes it a lot faster than if you chose another number (yes, it is all about speed )

256 is exactly one byte in hex, so it's the most optimized number for calculations. It's also extremely useful because you can bypass the /256 altogether and just pull the byte you need from whatever array it's in.