MOAR LEVEL!

Go eat some cheese

I can't find any sufficiently aged chees

With scrolling, you need an X offset and a Y offset, in pixels. I use T for the X offset, and S for the Y offset. Assuming you have a pointer to the tilemap in W and the start of the Tile sprites in Pic1, using A, B, C, D, and E as temporary variables...

ClrDraw

0-(T^8)->C
For(A,T/8-1,T/8+11
0-(S^8)->D
For(B,S/8-1,S/8+11

If {B*WIDTH_OF_MAP+A+W}->E
Pt-On(C,D,E-1*8+Pic1
End

D+8->D
End
C+8->C
End

Dispgraph

So when T is 8 and S is 8, you're at the top-left most corner of the tilemap. You can increment/decrement T and S using the arrow keys.

Okay, I spent the last coupla hours working on this. I set up a physics engine that has perfect collisions, using only pxl-Test. This thing has no tilemap



BTW, this is all 6MHz. Also, if you noticed from the screenie, the engine supports slopes as well. Source is attached.

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?

Yeah, Parser, it's the equivalent of going like this:

Data(1ST_BYTE_OF_APPV,2ND_BYTE_OF_APPV,3RD_BYTE_OF_APPV,etc)->GDB1

Okay, I've mentioned this before, and I'm not sure if it's in 1.0.5 cause I'm still using 1.0.3, but I would really like to say support for appvar absorption, where the source needs the appvar, but the executable doesn't. So, like when you absorb a Pic from TI-OS into an axe program, you go [Pic1]->POINTER, I'd like to see something like [appvANAPPVAR]->POINTER. Does that make sense?

I think the closing parentheses might be hurting you. I'm not sure if Axe does this, but Text(23,24,"1)------- might be registering the same way as Text(23,24,"1")