Thats what i thought O.o

Does it start at the beginning or in the middle?  Like if we move back 1, are we out of the appBackUpScreen?  Oh and epic program

So i am encountering a really weird bug in my game right now.  There is a section of code that is executed when a plasma ball reaches its goal, and only then.  Ive tested this with pauses and display, and confirmed that it only occurs when the plasma ball reaches its goal.  However, there is some code inside this block that is causing a RAM clear under certain conditions.

0->D
0->E

works fine, but

0->D->E

causes a RAM clear!  Whaaaaaaaat?  This bug isnt present when i compile as an application, and im convinced it has something to do with the program size, as adding a Pause 20 also makes the bug go away.  But, the program size is only 8460, which is underneath the 8810 execution limit I dont know whats going onn.  And either way, making the program *smaller* is whats causing the Ram clear, so that doesnt make sense...

How about just a battery bar?

Code: [Select]

.AA
ClrDraw
47->X
5->Y
0->V
Rect(0, 60, 96, 4)
For(A, 0, 200)
DispGraph
V-9.8->V
Y+V->Y
Pxl-On(X,Y)
Pause
If Y+2V>60
-V->V
End
End

Just wanted to point out some other things that you might want to change.  First off, there is no Implied multiplication in Axe, so things like 2V dont wok.  You need to do 2*V.  Secondly, there is no PEMDAS, everything is evaluated left to right.  So Y+2*V is really (Y+2)*V.  You should change it to V*2+Y.

Also, note that your initial velocity is 0, and then you Subtract 9 from it, making it negative.  This moves your pixel *up*, not down.  And whats more is that it will keep moving up indefinitely because you are waiting for it to go below the screen, but it just went off the top.

As for gravity, how it is done is simple.  There is a variable for velocity for each object, and ever frame, the position is incremented by the velocity, and the velocity is incremented by the acceleration.  For a deeper explanation you might want to check out my tutorial on Gravity and Acceleration over here: http://ourl.ca/4279

but wont it wrap around to 65536 since Axe is 16bit?

Well im not sure what the compiled program is doing, but i know what the problem is

V-9.8->V

Axe works with integers only, so this line doesn't do what you think it does.  I am surprised it actually compiles, but it might have to do with the fact that a period designates the start of a comment.  My guess is that it is reading the code like this

V-9

Which doesn't do anything to V, and so your velocity never changes, and your pixel doesn't move.

Might it also be useful when an error is produced in an included program which is archived, to say which included program the error occurred in? Otherwise it might be difficult to track down which included program is misbehaving.