Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: DJ Omnimaga on April 27, 2010, 02:33:11 am
-
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
-
Wow! That's actually really impressive! And the menu is really cool too. I especially like how you used grayscale and the speed animation looks really nice. And of course I get rickrolled in the process :P
-
Axe has built in Rick Roll support? Who would have guessed? =P Very fast too!
-
Heh that is awesome. Not only does it look like a good game because of the actual game play, but the fact that you're getting rick rolled while playing just makes it the ultimate game.
-
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)
:DispGraphr
: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 (http://www.cemetech.net/projects/basicelite/sourcecoder.php), © 2005 Cemetech (http://www.cemetech.net)
-
1600 bytes is OK for an asm game compiled from an 'interlanguage'.
-
Lol ok :P 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.
-
the executable would be about twice smaller than the executable.
lolwut?
-
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
-
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)
:DispGraphr
: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 (http://www.cemetech.net/projects/basicelite/sourcecoder.php), © 2005 Cemetech (http://www.cemetech.net)
Edit:
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. ;)
-
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:
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 x.x. He should have pointed it out to me more directly D:
-
Update:
-Did a few more optimizations, thanks to Quigibo for one of them.
-Added highscore support
-Changed some text to lowercases.
-Fixed issue when exiting. Score text would instantly dissapear. Putting a getkey command there fixed it
-
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
-
Nice! Looks pretty good. (I haven't tried it yet, but the screeny seems okay.)
This would probably be a good program to make into a tutorial for Axe, since it shows many of its features.
I just wonder how obfuscated the code may have become during optimization...
-
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
-
Sometimes code can just get really confusing after extensive optimization. For example, lots of good BASIC programs and ASM programs. If the code can be followed with relative ease, then ignore that particular comment.
-
Aaah ok. Well, most of my optimizing are stuff like 1->A->B+1->C instead of 1->A:1->B:2->C, and Pong example in the manual uses those IIRC. Besides that, the game code was not really optimized much since it was my first Axe game ever XD. Some of my old BASIC projects (like Reuben Quest series, The Reign Of Legends 3, Metroid II and xLIB xLIB Revolution) are extremly messy and impossible to understand, though x.x
-
Just curious, if someone were to go through your old BASIC games how much do you think could be optimized out?
On a "On-Topic" note. It looks really cool :) I haven't had a chance to try it out but I shall soon :D
-
Just curious, if someone were to go through your old BASIC games how much do you think could be optimized out?
On a "On-Topic" note. It looks really cool :) I haven't had a chance to try it out but I shall soon :D
I wish them good luck x.x the code is really hard to understand
thanks btw
-
How much size or speed do you think could be added to them if someone attempted such a feat?
Just tried the game, addicting :) Great job.
-
thanks, and for the code I'm really unsure x.x Idk if it could be shrinked down much but it may run faster and have no memory leaks.
-
Huh, interesting. Would be an interesting thing to do :P And you're welcome.
-
This tunnel was brought to you by Rick Astley.
The tunnel itself seems a little weird...gets bigger and smaller randomly. Still, the point was to show Axe's capabilities, and they are really, really cool.
-
Oh it gradually shrinks down actually. However, the way it is coded, when it goes diagonally, it seems the diagonal paths are smaller.
-
This was just updated to Axe 0.3.0. No changes to the tunnel, except that the title screen now runs at 6 MHz to avoid issues with grayscale on real hardware.
Also DCS 6.6 has an issue with the DCS build of this game. Use the others for now. The size is roughly the same, but it increased a bit due to slowing down title screen to 6 MHz then back to 15 MHz once game starts.
-
I was bored once again and made another RickRoll tunnel, this time using 4 level grayscale. I am not sure if it looks good on calc, though :P
It also runs at 6 MHz through the entire game, unlike the monochrome build.
-
Thats really cool! The thing i like about the way greyscale is handled, is that it allows the grey to appear as a kind of transparency, like how the tunnel is grey, but everything behind it gets a little darker. It makes it look really cool :)
-
Yeah me too, usually you can simply have the foreground stored to the back buffer then display stuff on the top. You can also do the opposite if you want the foreground to be lighter, for example
Btw the title screen is still 3 LV
-
Looks great on the emu :) glad the multi-grey problem you were having was fixed, looks great!
-
well, I simply chosen game gray then set it at a different level that is somewhat high and it somehow fixed it
-
What level were you at out of curiosity? o.O Because it looks great :]
-
Perfect gray, level 7.
It doesn't work fine with every game, though. With Pokémon, I believe I had full of scanlines. It may depends how fast the grayscale is refreshed.