Thanks!  Fixed.

Its not just enabling and disabling the [ON] interrupt, you also have to set up a vector table in RAM for the interrupt as well as some code to handle the interrupt.  Not only that, but I also have to save the state of the stack and then restore it when the interrupt is called otherwise, it will never break out of the code when you're in a subroutine.  I'm sure it wold be at least 100 bytes and in addition it would have to use about 300 bytes of free ram that would no longer be available for the programmer.

You have to click on what I first thought was an ad to start the game.  You don't click the dot like the title says, but just hovering over it is enough to win.  Its mildly amusing, although I have to admit, its way too easy on my tablet compared to using the mouse.

I did a few optimizations for you, hopefully you'll understand them and catch on.  Most of the other optimizations you can do are with the program flow rather than actually optimizing your code.  For instance, you only use one division routine in the entire code, but you can replace it with a multiplication (High S value corresponds to low speed) instead to avoid needing the routine at all which can saves like 20 bytes or something.

:.DJTUNNEL Axe Parser Tunnel clone
:[80C0E0F0E0C08000→Pic1
:[FFFFFFFFFFFFFFFF→Pic2
:"SCORE:"→Str1
:"AXE TUNNEL"→Str2
:"2010, BY DJ OMNIMAGA"→Str3
:"SPEED:"→Str4
:0→D→P+1→S+1→Q
:8→C+1→R
:30→A
:10→W→T
:Full
:DiagnosticOff
:ClrHome
:ClrDraw
:For(Z,9,21
:Line(0,Z,95,Z
:End
:Line(0,56,95,56
:StorePic
:ClrDraw
:For(Z,8,22
:Line(0,Z,95,Z
:End
:For(Z,56,63
:Line(0,Z,95,Z
:End
:DrawInv
:Fix 5
:Fix 1
:Text(20,12,Str2
:Fix 0
:Text(14,57,Str3
:Fix 3
:Text(5,35,Str4
:29→I
:5→J
:2→K
:Repeat Z=54
:DS<(K,12)
:DispGraph^r
:End
:DS<(J,9/S)
:Pt-Change(I,34,Pic1)
:I+1→I
:If I=86
:29→I
:End
:End
:getKey→Z
:Z=3-(Z=2)+S→S
:If S=6
:5→S
:End
:!If S
:1→S
:End
:End
:ClrHome
:ClrDraw
:For(Z,10,50
:Line(0,Z,95,Z)
:End
:Repeat W=6 or getKey(15)
:P+S→P
:DS<(C,8)
:rand^2*2-1→D
:End
:R+D→R
:!If R
:1→R
:End
:If 62-W<R
:62-W→R
:End
:If getKey(4)
:A-1→A
:End
:If getKey(1)
:A+1→A
:End
:Pt-Change(0,A,Pic1)
:Line(95,R,95,R+W)
:DS<(Q,S)
:DispGraph
:If pxl-Test(0,A) or pxl-Test(0,A+6)
:Goto GO
:End
:End
:Pt-Change(0,A,Pic1)
:Horizontal-
:DS<(T,99)
:W-1→W
:End
:End
:Lbl GO
:Fix 4
:Fix 2
:ClrHome
:Output(0,0,Str1,P►Dec
Generated by SourceCoder, © 2005 Cemetech

Edit:

Quote from: Silver Shadow on April 27, 2010, 12:42:34 pm

Quote from: DJ Omnimaga on April 27, 2010, 12:30:03 pm

the executable would be about twice smaller than the executable.

lolwut?

In source code, sprites are stored in hex form. A 8x8 sprite takes 16 bytes in the source. When compiled, that sprite shrinks to 8 bytes. Same for any hex data. Say you have a game with 20 KB of map data and 0.5 KB of code. The maps will end up 10 KB and the code around 1 KB

It was funny becasue you said executable was smaller than itself.  You meant the source would be about twice smaller than the executable size.  ;)

Yeah, when I add >Dec support for Text() I will also add the >Frac.

Temporarily, you can use the Output() feature to do this but it has to be aligned.

That's coming next version for sure.  There isn't a built in OS-call to display an integer in an arbitrary position (that I know of) so I have to do a little work around by converting it to a float and then displaying it.  Its slower, but its somewhat small.

Binary support means all of the above.  Individual bit operations as well as a new number representation.

The only problem with tile mapping though is that you have to add the entire picture even if you only add a couple tiles.  Also what do I do about the last row of tiles?  Since pic vars are only 96x63, do I just assume the bottom bits are all zeros or do I ignore that whole row of sprites?

Random seed generation is not possible like basic becasue the random numbers have a real randomness factor to them that prevents any predictability with a given seed.