I didn't hear much about that game but I think you were working on a calc remake back in the days, right? I need to check that stuff out at one point.

Yeah, I tried making it for the TI-86 around 11-12 years ago, but A) I bit off more than I could chew, I wasn't ready for such a large project, and B) the ~10K code limit on the 86 was a big issue. If I do attempt it on the 84+CSE, it would be a multi-page app

Great post DJ_O! And well done to everyone involved in those games

I have the following (roughly in order of purchasing):

TI-83
TI-84+
TI-86
TI-89
TI-82
TI-85
TI-84+CSE

if (bored && hasSpareTime) {
  makeYetAnotherAlienBreed();
}
else {
  daydreamAboutAnotherAlienBreed();
}


That's what I meant yeah, 256 colours based on a colour index table to convert them to 16-big BGR for the LCD driver My terminology probably isn't the best, as this is my first time finally tackling this kind of thing lol

My utility converts the .bmp to 256 colour binary data, and then I used Jimmy Mardell's Huffman compression tool. On the calculator I used slightly modified version of his decompression routine, which for each byte it decompresses, then looks it up on the colour table and sends the respective 16-bit colour to the LCD.

Yeah I'm thinking 16 colour nibble data too for sprites, tiles, etc. for any games I make. Well to clarify, 15 colours and one transparent, provided that it's workable. I may or may not use the half-res mode, depending on what the game is, and how practical it is.

How are your tests going?

Here's where it's currently at. This is a 180x171 image, compressed in 8-bit colour. The program uncompresses it and converts back to 16-bit BGR on the fly.

An uncompressed 180x171 16-bit image would take up 61560 bytes, but the image data used in this program takes up only 6828 bytes, plus 512 bytes for the colour index table used to convert from 8-bit to 16-bit. Of course, the compression is fairly good on this image, as there aren't a lot of different colours being used..

I should note that I'm very new to working with 8-bit / 16-bit colour conversions, etc. so I wouldn't be surprised if this could be done better. I'll release the updated code in the next day or so once I've cleaned it up and tested it some more.

Apologies for my iPhone/hand reflection on the calculator when the screen goes dark

It would be nice if image compression could be integrated into DCS8 or some standalone lib for BASIC programmers as well. How fast is it for full screen (or at least 160x240) animations?

I'm sure some kind of library will get coded up eventually. I have some ideas for it, but I don't have a lot of experience in creating ASM tools for BASIC programs. I'd love to give it a try (and maybe I will!), but no doubt someone else could do a better job.

I haven't done any animation testing yet, although tr1p1ea did a scrolling background test running in 160x240 mode, and it looked quite fast!

I think the best would be to use 256 colors (or 255+transparency) or even less, then use RLE compression or something.

Can we expect an Alien Breed, Banchor or Centipede port in the future?

Yeah I was thinking about 8-bit color images today, which I'll try over the next few days, as well as some other cool ideas.

I do have a lot of ideas for different games I'd like to make on the 84+C, but I won't promise anything until I see what I'm capable of actually doing with it first lol. I'm thinking my first game will be something new that I haven't made before though