Thanks everyone!

AssemblyBandit: Good ideas about the border space on the screen, I've added it to my to-do list

Here's the first screenshot of Spaze Invaders on-calc. Apologies for the quality, the colours don't show up very vibrantly as it's just a photo taken on my iPhone Currently the game loads up and initialises the game play screen as shown. The player can move from side to side and shoot the laser. Aliens don't do anything as of yet, but the shields/barriers function properly.

I'll be sure to post more shots as I make progress

In xLIB i have my font data stored as 1-bit and simply have any bits that are 0 as transparent. But i do see what you mean with the above. It doesnt really matter how it works, as long as it works .

Hehe, I also have my font data stored as 1-bit The catch with the sprites is that sometimes I need it to draw a black pixel, to erase part of the old copy of the sprite drawn behind it, because I'm not erasing the whole sprite before drawing, due the flickering effect

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

Isn't space invaders a classic Atari game? ^^

anyways, nice idea, hope you'll succeed!

Correct Movax's TI-83 version was pretty much a clone of the old Atari 2600 / arcade game.

I think it would be possible with assembly, but it's fairly advanced (unless I'm over complicating things, which is quite possible... )

I believe you could write a program that would install an interrupt hook that will run in the OS when the [PRGM] button is pressed, and execute your own "program menu". Unfortunately, I'm no expert when it comes to interrupts and hooks 

I've long hoped for a really cool Sonic game on the 83/84(+) series. I wonder how feasible it might be on the 84+CSE? Horizontal (hardware)scrolling should be fine, but I don't think vertical would be an option (alas, that is why Alien Breed on the 84+CSE will probably never happen )

Hey James, whats the compression ratio using your huffman program? When I try to use the build.bat file it says that it cant create ab.bin and I dont get the .asm file. I made IViewer and it stores images as app vars and displays them but the max size for the app var is 65400 bytes. I cant fit complex images such as a jungle with a lot of leaves using only RLE unless I reduce the quality to an unacceptable level. From what I've read about huffman compression, it sounds good for text but is it better than RLE for images?

It depends on the image. I'm certainly no expert on compression and the various techniques, Huffman just tends to be the one I use thanks to the tools that Jimmy Mardell made available with Sqrxz.

Did you want to email me the original image you're trying to compress? I'd be happy to see how it works with the program I've been working on (although admittedly, I haven't done any work on it in around a month, but it's still fairly fresh in my mind )