It's a crosspost. I think I promised that I'd post here about it when I was done?
See attachment at bottom of post for download

Screenshot of title screen and gameplay. If it's not animating, it's because imgur wants you to view it on their site


I wanted to rewrite another game for the CE and this time I thought of that really fun game that I played in high school as often as I could get away with. That's pretty much it, except it took much longer than expected to finish what was supposed to be something pretty simple.

The starting idea was to roll a ball along a path which scrolls downward, so I wrote code to generate then animate the path. I'd originally wanted to draw pairs of triangles for each "square" so I could transform those edges later on when I added the 3D perspective. The result was freakishly slow, so I instead wrote an assembler routine to try to draw what is basically a trapezoid (given that's basically what each tile is when rotated along the Z-axis). I was unable to get it to work right, so I went with coding a larger assembly routine to draw the entire board at once. I still hadn't worked out what needed to be done to make perspectives work but I had enough to draw something.

The path


I now needed to make a ball that looked like the rolling thing from the original game. Except, my "artistic skills" was woefully lacking in that department, so I took a detour to my fun Python setup to see if I could render frames for a rolling ball sprite that way. Turns out, I knew too little about 3D... anything... so I had to break out some textbooks and stare at wikipedia for days until I figured out something that would let me rotate a sphere in exactly the way I wanted it to.

Haha no.


What is this i dont even


what the flying...


Finally, something usable


With a bit of little cleanup and paint.net magic...


Perspective. This is what caused me nearly endless grief. The lookup table generator was at the beginning slower than the process it took to compile the program. The assembler routine responsible for drawing the board needed to be rewritten several times. I also started using Git to version the project since I didn't want to mess up and having to scrap everything (yet again).

Behold, a failure


That doesn't look right


Starting to look reasonable


A few more tweaks to the assembler routine made the path solid. Wrote another assembler routine to fill in the background faster, with a custom palette to give it that gradient. Changed how jumping worked to give it a nonlinear arc and to increase the size of the ball as it moves upwards to simulate additional perspective.

It's almost there


From there, I added:
* Explosion animation on quitting
* Falling animation if you miss the path
* Help
* High score retention

I'd also reduced the frame count of the explosion and reduced the color depth of the title graphic because 20KB for a game this simple just isn't acceptable. I also modified the perspective a bit more to give it a more faraway look, tweaked speeds a bit once geekboy1011 (final tester) mentioned about how ridiculous it was on hardware, and made the random path generator less cruel about unfair gaps.

Would an extra 4KB have been worth keeping the high quality title graphic?

And here we are at release 0.1. Check the project out on GitHub

Very nice. This game brings me back memories of the old Plain Jump game for the 83/83+

Could you use one buffer for the rectangles and just draw a line at the bottom of each rectangle every frame and not erase the previous one? All you would have to do then is draw 16-24ish horizontal lines each frame. (and do the bit of trig to figure out where it should be) You would need another buffer for the screen and another for double buffering but drawing the colored background then copying over the rectangles then drawing the ball should be very fast.
All that probably isn't needed because it looks really smooth as it is. It was fun to think about though

I double buffer the whole thing to help prevent artifacting, so introducing a third buffer isn't something I want to do due to soft memory constraints. Were I to try it anyway, merging two screen-sized buffers is a very slow process even after somewhat minimal processing is done on each. The program is already fast enough as it is (pushing close to the maximum allowed framerate) since I'm doing some trickery to accelerate the rendering, such as push slides to render the background and drawing the lines via lookup table.

You raise a good point about the lines thing now that I think about it. If I kept track of each of the two buffers, I could skip out on a lot of redraw costs by keeping and redrawing the stuff behind the ball sprite in each of the two frames to allow movement, do some tricks with the score to redraw the background behind that, and take a differential between the current index and previous index in the LUT to partially redraw the background behind the tiles. This way I could do away with drawing the background altogether (apart from init) and only need to partially redraw the field at the cost of added complexity with the ball.

I'm just a little iffy on the idea of changing the line renderer, though, since that would increase the complexity of something that's already at the edge of what I'm comfortable with. But it would let the program maintain a solid 60fps. Something to think about for v0.2