[Ti-Concours]Jetpack 8x+

[Matrefeytontias]

Hi guys !

Here is my Ti-Concours entry for the 3rd round ! Jetpack 8x+ is a port of the famous game Jetpack Joyride of the iDevices, for all the 83+/84 calculators

I started it something like a month ago, just at the end of the 2nd round, so I nearly finished it, even I can add a lot of features.

In this game, you are Barry, a man who stole the secret Jetpack, and you have to escape the labo alive by avoiding zappers (electric arcs), rockets and lasers.

Of course, the game is endless and you just have to run the furthest you can.

Here is the last screenshot (it's outdated !) :



I still have to increase difficulty when you run, else a good player will run and run and run and run and run ...

[Wellen]

Great one !
Is the game on-calc at the same speed as on the gif ? If so, I think you could increase the speed a little bit, or make the game scrolling faster and faster.

[Darl181]

Just had a random thought: if it scrolls one pixel per frame and you get it to run at ~60 fps, you might be able to get away with having a monochrome background and have the scrolling act like the scanlines.  Then it might run a bit faster, only having to scroll one buffer?
Not sure how running would be done, tho..aside from maybe scrolling three pixels at a time or having the normal walk be slowed down?

[aeTIos]

wellen,m you accidentally doiuble posted.

edit accidentally made some typos

[Matrefeytontias]

Yeah, I think use only the background of the back-buffer will speed it up a lot, I'll test

[Matrefeytontias]

Up !

I removed the back-buffer of the background image, which downsize the program of 1512 bytes and speeded it up a lot !

Here is the real last screen (I added Pause 20 at the end because the program was too fast ) :

[Keoni29]

Just shift the back buffer and only draw the new line you've shifted in!

[shmibs]

judging from the fact that you are shifting the buffer before updating the screen, i'm guessing you are, indeed, drawing the entire background every frame rather than just the rightmost column of pixels. if you were to swap drawing the entire background in monochrome for drawing only the rightmost column it would mean a change from 96 sprites for monochrome to 32 for greyscale.

if you're doing it that way already, though, then my mistake

[Matrefeytontias]

I can't do that, I need to use ClrDraw each frame because of particles anims and the very large amount of sprite I can't mask. So I clear the screen and rewrite the whole shifted buffer each frame.

[shmibs]

you can, indeed, do that. if you're going to keep it monochroms, just draw the background on the back buffer and copy it over, and if you want greyscale, make a couple of backup buffers with an appvar or something. it will be a LOT faster. if you're drawing the background in monochrome, it's 16 pt-on( s and a single conj( instead of 96 pt-on( s

[Matrefeytontias]

Oh no, I'm not using any drawing functions, just bit storage in L6, so it's really fast (I use Horizontal - and Copy(Pic1BG,L6))

[shmibs]

wait, so do you have separate frames for every look the background can take, then?
if so, then that would be very fast, absolutely massive, and not require horizontal at all. if not, then i don't understand...

[Matrefeytontias]

it would take 48*1512 bytes of hex

That's not it, here is how I do :

• I copy the two first rows of pixels at the end of the buffer
• I shift the buffer
• I copy the buffer to the screen

The screen is updated at the end of the frame.

[shmibs]

so you're copying with a loop that runs through the data, copying line by line? that still seems like it would be slower than the sprite commands.

[Matrefeytontias]

Maybe, but the fact is I have the whole image in plain hex, and that's not the good format for sprite commands. Also, bit manipulation is really fast ...