Omnimaga
Calculator Community => Other Calculators => Topic started by: DJ Omnimaga on October 25, 2013, 03:58:54 am
-
This is the xLIBC version of my color Tunnel game, for use with Doors CSE 8.0 on the TI-84 Plus C Silver Edition. Originally released for the HP Prime graphing calculator and written in HP PPL language, this 84+CSE demake was adapted to run within the limitations of the lower end 15 MHz platforn, as well as those of TI-BASIC and xLIBC.
(http://img.ourl.ca//hptunnelxlibc.png) (http://img.ourl.ca//hptunnelxlibc2.png)
Note: This is not meant to compete against AssemblyBandit's Tunnel game, which is much better than mine, but rather to show an unconventional way of using xLIBC by tr1p1ea (included in Doors CSE 8.0) and an example of what kind of game can be done with it. The unconventional way in question is that xLIBC splits the screen in two GRAM buffers, in 160x240 mode, where only one can be drawn on at a time. In order to draw on the other, you must tell xLIB to toggle GRAM areas. Since this Tunnel game uses the screen scrolling capabilities, this required extra code to detect when I need to switch to the next buffer, also making it a major PITA to tell which part of the road needs to be updated. This is because xLIBC was never meant for that kind of game, but rather tilemap-based games with no scrolling.
It runs around 4-5 FPS on a real calculator, while the original HP Prime version runs at 60 FPS with timers removed.
-
It runs around 4-5 FPS on a real calculator, while the original HP Prime version runs at 60 FPS with timers removed.
Holy crap. O.O
-
It runs around 4-5 FPS on a real calculator, while the original HP Prime version runs at 60 FPS with timers removed.
Holy crap. O.O
How is that surprising ?
~20 years old 15 MHz z80
vs
recent 400 MHz ARM
... both driving a 320*240 color LCD :P
Anyway, nice, DJ_O.
-
You mean a 2D acceleration chip. :P
-
You mean a 2D acceleration chip. :P
I'm not aware anybody has confirmed that this chip is actually used by the Prime's software.
-
Ah, yeah, I forgot about that.
If it's indeed used, and as Lionel said, it's still to be confirmed..., it's one more thing that makes the Prime way superior in terms of graphics possibilities (especially when comparing to the z80).
-
Also the Prime BASIC has xLIBC like commands such as sprites and rectangles that TI-BASIC lacks on Z80 models. This Tunnel game would never be possible in pure TI-BASIC.
thanks by the way! :)
-
Looking nice! :)
-
Thanks. :D That reminds me, I need to try sprites+scrolling and only display a few platforms at a time per loop iteration. I am curious if the low FPS comes from the BASIC language or the fact I am displaying 3 rectangles for a total of 16x210+ pixels per frame. I also use two random commands per loop.
-
Looks awesome! I wonder what can be done to speed it up. I can see an adjustment to the way the screen is scrolled which might help?
-
I guess one nice feature addition for Real(0,1 would be a mode that merges GRAMs and let you display stuff anywhere on the screen (so sprite X can be 0-312 rather than 0-152). Not having to constantly switch GRAMs in the Tunnel game would definitively speed it up I'm sure. By the way here is the source code:
::DCS
:"8888888888888888111111111111111199999999999999993333333333333333555555555555555575775555565555557677656776755555C6776667767755762277666776776676C677666776776676767766677677667676776667767766765655666775776676555556555557667655555555555566555555555555555555"
:0→B
:0→O
:1→C
:50→W
:0→T
:24→R
:0→P
:65→A
:0→G
:1→K
:real(0,1,1
:real(8,1,1
:For(θ,0,1
:For(Z,0,1
:real(0,3,4,28,0
:End
:"HP PRIME TUNNEL/TI-84+CSE DEMAKE
:For(Z,1,7
:real(6,0,15+Z,40,Z+240θ,47,0
:End
:" 2013/WWW. .ORG
:real(6,0,16,96,255,47,0
:"OMNIMAGA
:real(6,0,48,104,24+224θ,0,1
:End
:Repeat Z=21 or Z=105
:getKey→Z
:real(8,2,160
:real(8,2,0
:End
:For(Z,0,1
:real(0,3,4,28,1
:End
:real(8,1,1
:For(Z,0,1
:For(θ,0,5
:real(7,9,0,3θ,160,3,26+θ,0
:End
:For(θ,0,3
:real(7,5,0,18+θ,160,18+θ,θ,0
:End
:real(7,9,0,22,160,20,5,0
:real(7,9,0,42,160,50,229,0
:real(7,9,0,92,160,28,5,1-Z
:End
:real(8,1,1
:real(6,0,0,0,255,5,0
:While K
:real(1,1,0,A
:real(2,1,0,0,0,6
:real(1,0,0)→A
:real(8,3,16
:R+Ans-8→R
:If R>96-W
:96-W→R
:If R<2
:2→R
:T+1→T
:If T>10
:Then
:0→T
:W-1→W
:End
:(real(7,1,O,A)>7) and (real(7,1,O,A+7)>7)→K
:real(7,9,O,A,5,8,224,0
:real(7,9,O+1,A+2,7,4,189,0
:O+16→O
:real(8,3,3→C
:real(8,1,B
:real(7,9,O-16,22,16,R,C+3,0
:real(7,9,O-16,22+R,16,W,C+227,0
:real(7,9,O-16,22+R+W,16,120-(22+R+W),C+3,0
:real(8,1,not(B
:If O=160
:Then
:0→O
:not(B→B
:real(8,1,not(B
:End
:real(8,2,O
:P+1→P
:End
:For(Z,0,7
:real(0,3,2
:randrandrand
:End
:For(Z,0,1
:real(0,3,4,28,1
:End
:"P
:For(Z,1+int(log(P)),1,{-}1
:Ans+sub("0123456789",1+int(10fPart(P/10^Z)),1
:End
:sub(Ans,2,length(Ans)-1
:For(Z,0,2
:real(6,0,88+Z,56,11Z+9,0,0
:End
:"SCORE:
:For(Z,0,3
:real(6,0,32+Z,56,193-62Z,6,0
:End
:Repeat Z=21 or Z=45 or Z=105
:getKey→Z
:real(8,2,real(8,3,5
:End
:For(Z,0,1
:real(0,3,4,255,1
:End
:real(0,1,0,1
-
I must say the style of the program is cool, i tried to recreate it before you posted your code and came up with this:
:real(0,1,1
:real(0,3,4,238,0
:real(7,9,0,0,160,16,28,1
:real(0,3,4,238,0
:real(7,9,0,0,160,16,28,0
:0→X
:120/2-3+16→Y
:0→G
:10→S
:5→C
:56→T
:Repeat real(2,0,0)=15
:real(8,3,12→R
:real(7,9,X,R+32,S,T,238,0
:real(7,9,X,16,S,R+32,C,0
:real(7,9,X,R+T+32,S,120-T-32-R,C,0
:real(8,2,X+160
:real(8,1,not(G
:If real(7,1,X+6,Y+1)≠238:Goto 1
:real(7,9,X,Y,8,6,192,0
:real(8,1,G
:X+S→X
:T-.1→T
:5(C=7)+7(C=5)→C
:real(2,0,0
:Y-6(Ans=4)+6(Ans=1)→Y
:If X=160
:Then
:0→X
:not(G→G
:real(8,1,G
:End
:End
:Lbl 1
:real(0,3,4,255,1
:real(0,3,4,255,0
:real(0,1,0,1
No doubt any early xLIB code can be optimised. I wonder if i can add another function that can offset the GRAM window as well without automatically updating the LCD. I wonder if that will help speed things up?
-
That could work as well, as long as it isn't too hard to choose where to display stuff and easily let us move around