I've finally started work on my first 84+CSE project! Seeing as Spaze Invaders (by Hannes "Movax" Edfeldt) was the first TI calculator assembly game I ever saw 15 years ago, I figured it's only fitting that my first 84+CSE project should be to port the classic TI-83 game over and colourise it!

The current plan is to make as much use of Movax's original code as practical, but I'll obviously be re-writing all of the sprite & LCD routines, as well as adding colour to the sprites (and doubling them in size to suit the larger LCD). The sprites themselves will still have the same retro look. The LCD will be run in 160x240 mode to optimise speed and sprite data, seeing as the graphics won't be high resolution.

This image is simply a mock up at this stage, but I should have some on-calc progress to show in the next week or two!

Win. There is also Calcuzap for the CSE by Patrick Davidson but this one seems very promising too

By the way, will the game be full screen? (as in, take the entire screen height and 160 pixels area, unlike in the mockup above)

Looks nice! I haven't played that game in forever!

Interested in how you are handling drawing, are you buffering at all?

Interested in how you are handling drawing, are you buffering at all?

No buffering at this stage. I'm only drawing sprites when required (ie. during initialisation and then only when they move after that). The sprites are drawn on the black background. If the sprite moves, the following steps are taken:

• If the sprite moves right 1 pixel, erase the left-most column of the sprite. If it moves up 2 pixels, erase the bottom 2 rows of the sprite, etc.
• Re-draw the sprite in it's new position.

Although it's a little more painful, this avoids the flickering that occurs when erasing the whole sprite before re-draw each time. I'm already anticipating what this means in future games that I may make that would have a background behind the sprites, ie. having to store the background before drawing the sprite, then erase a side of the sprite with the right row or column of background data, shift the background data, get the new row / column of background and then re-draw the sprite. Having said that, there are probably easier ways to do this that you've already discovered perhaps?

Have you thought about making it 3x then using 240x160 mode instead or would it be too slow? It would still fit on the screen, although the score text would look a little small in comparison to ships. You could maybe use the Atari 2600 text, though. It looks nice as it is now, though, but since the calc screen is small, I fear that a bunch of people will complain about how the game view is too small and that it hurts their eyes. Remember the many complaints about Gemini 3D and Wolfeinstein 83+ regarding that issue.

4x is out of the question, though, since it would require removing some ships and making them closer, which would alter the gameplay. Scaling them 2x horizontally and 3x vertically could be ok if you don't mind stretching things up a bit, although it would still leaves an empty space on each side.

Else, if you stick to the smaller view, you could maybe add a green border surrounding the game area instead of just the line below?

The first concept drawings and first couple of builds I made actually did have 3x sprites (24x24 for normal enemies), but it just looked a little clunky to me. I'm actually running in 160x240 resolution at the moment; if I were to go back to 3x scaled sprites, I'd need to return to standard 320x160 resolution, which would mean a lot more reading & writing going on with the lcd. It also means either having more sprite data, or writing a more complex (slower) sprite routine that automatically scales up 8x8 sprite data. I'm already using a 4-bit (16 colour) format for sprites to keep their size down. Mind you, as I'm typing this, I've just thought of another way where I could use a 2-bit format for sprites to slice their data in half again.

Anyhow, for the time being, I'm preferring the 2x scaled look, but it's not set in stone

All the sprites are 1 colour only, but some of them have transparency near their right edges, eg. the player laser beam is only 1 pixel wide (stretched to 2 pixels in 160x240 res), but the sprite data is (currently) stored as 2 pixels per byte, so the right pixel (least significant nibble) is transparent, so that it doesn't draw black over the edge of another sprite as it moves past.

I remember the last time I played space invaders, it was back at a retro convention. The place was so cool.