Note, 33 fps gif, need Opera/Firefox or a browser supporting gifs higher than 10 fps to view it.

15 MHz speed. Tool-assisted gameplay using WabbitEmu.

Note this is not the official version. The real version has no rickroll and only the title screen has grayscale so gameplay is faster

Axe has built in Rick Roll support? Who would have guessed? =P Very fast too!

lol thanks :P

Last nigth I was curious and wanted to experiment with the grayscale command in the middle of gameplay, seeing how fast it was outside gameplay, and when I saw everything gray remained static, I thought: hey! A nice rickroll occasion! :P

Anyway here's the screenshot of the real version, the official executable and since it's my first Axe game and would like to see what I could optimize (the executable is over 1600 bytes x.x) and also for people learning, I'm also posting the source code.

This simple game was started as I wanted to experiment with the Line() command. Grayscale wasn't even planned initially :P

Note: the game is set to run at the max calc processor speed. Since it was emulated on a 84+SE, it will run twice slower on a regular 83+. However it's still extremly fast on it (and easier to play) :P

:.DJTUNNEL Axe Parser Tunnel clone
:[80C0E0F0E0C08000→Pic1
:[FFFFFFFFFFFFFFFF→Pic2
:"SCORE:"→Str1
:"AXE TUNNEL"→Str2
:"2010, BY DJ OMNIMAGA"→Str3
:"SPEED:"→Str4
:1→S
:9→R
:0→D
:8→C
:30→A+10→W→T
:0→P
:2→Q
: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=0
: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)
:If rand<32767
:‾1→D
:Else
:1→D
:End
:End
:R+D→R
:If R<1
: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

Lol ok but yeah I still wanted to show it in case some people got some other tricks to achieve what I did, that could make the code even smaller.

Also I don't use much data. Had this been a game where almost everything is data, the executable would be about twice smaller than the executable.

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

ooh thanks a lot for pointing those out! The !if ones are stuff I missed but I didn't really realize much ways to do some of the others.

I corrected something in  your version, though:

:30→A
:10→W→T

Changed it to

:30→A
:40→W→T

Else the road ended up 10 pixels large on startup instead of 40

Your optimizations made me discover a few more, too (I moved 29->I, 5->J and 2->K at the top to allow some and make the code more organized). I'll prbly need to re-check the optimization tricks section and the list in the txt file. I couldn't figure out a way to get rid of the division yet without changing the animation speed, but so far I saved 51 bytes, allowing my game to go under 1600 bytes ^^

Thanks again

And

Edit:

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

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.  

aaah my bad I didn't notice that typo . He should have pointed it out to me more directly

finally it's done!

http://www.omnimaga.org/index.php?action=downloads;sa=view;down=528

Future versions may be done for MirageOs/Ion/DoorCS too, but not until I figure out how to get around the bug that causes MirageOs screen to say my game takes 65535 bytes when exited

Maybe it could be put as tutorial indeed. A lot of people start a language by programming a tunnel game. What do you mean by the code being obfuscated, though? Do you think it would be better in a tutorial to show both the code before optimizing and after? Some stuff might be a bit confusing for an early Axe programmer, altough maybe he could be fine by looking at the optimization tricks and table