Since 3.5 years ago when I decided to do Alien Breed 5, I've had a rough plan in my head for it to be a 3-part game, ie. the first main release, followed by two additional campaigns with new features to be added later. I've recently started working on the 3rd and (most likely) final part. It's still very early days, but I've already gotten a few cool things done.


As usual, there will be a new campaign, although it will be different in structure to Episodes I & II. There will also be new gameplay elements, some new enemies, more achievements and potentially some slight graphics tweaks in the form of more tile animations.


So far, I've reworked the level file format to allow for some of the additional gameplay elements, which will allow for more things to happen in levels. The level editor pretty much had to be rebuilt from scratch, as well as making a simple program to convert the existing Episode I & II data to the new format. I'm now halfway through implementing the calculator-side changes to all of this, so that the game correctly interprets the new level format and starts incorporating the new elements.


Additionally, whilst this will still include the standard TI-83+/84+ flash application release, over the last 36 hours I've been doing some tests to see how viable it would be to include a build for the TI-84+CE!


I've drawn inspiration from MateoConLechuga's Mono2Color project for the TI-84+CSE, and after a few experiments determined that I'll most likely have to stick with monochrome tiles & sprites so that I can run the LCD in 1bpp mode, otherwise the frame rate gets way too slow. Below you can view a demonstration showing the game in 3 different zoom levels (x1, x2 & x3). As you'll see, x1 moves super quick, x2 moves roughly the same speed as the TI-83+/84+ monochrome version (within 1fps), and x3 is a bit slower again (around 7-8fps slower). Of course this demo only includes the scrolling background, no player/enemy/gunfire sprites. However, all the tile drawing & sprite rendering is done on a 768 byte buffer, the part that slows things down is scaling this 96x64 resolution buffer up to either 192x128 (x2) or 288x192 (x3). I'm confident that drawing the sprites over the tilemap will have minimal effect with the CPU speed of the TI-84+CE (but this will be my next few experiments).


The 768 video buffer -> vram drawing/scaling routines were written fairly quickly, so I might be able to optimise them a little. I'll continue playing around and see how I can improve it. At the very least, I'd like to have a TI-84+CE version with a play screen of 192x128.

Do you use parctial redraw? Because different screen sizes run at different speeds, it seems to me you are not
Anyhow, this is cool
This reminds me i need to start working on my mincraft port to the CE

That sounds like it'll be a pretty good and fun game
yes, non CE and CE support, always great to have both, can't wait to try it out.

Awesome, I'm glad to hear you were able to get a nice speed boost.

With some assistance from MateoConLechuga, the 3x scaling/drawing routine is now running substantially faster on the TI-84+CE. Thanks Mateo!

Hey James, those new features sound awesome! Also nice to hear that @MateoConLechuga was able to lend you a hand. Great work guys! Maybe you can add a splash of colour now? 

I have some ideas on how to integrate a minimal amount of colours without slowing things down, although for the most part I think there will still only be two colours on screen at once in terms of the "play field" (the planned HUD could use up to 256 colours). This is simply because the video buffer is still only 768 bytes (96x64/8 = 1bpp) to enable faster scrolling and tile/sprite rendering behind the scenes. But it's still early days so who knows what I might be able to achieve - I'll be sure to experiment further!

With some assistance from MateoConLechuga, the 3x scaling/drawing routine is now running substantially faster on the TI-84+CE. Thanks Mateo!

It seems like it'd be nicer if it showed more of the map, instead of scaling everything up.

I've been thinking of a way you could somehow attach color data per tile, each tile would still only support two tiles but you could do something similar to RLE where you'd have an extra buffer keeping track of the current palette. Something like:
        ; bit 7
        exx
        ld a,(hl) ;hl' points to palette array
        exx
        sla d \ adc a,aIt's a bit slower and you'd have to inc hl' at the end of each djnz iteration. You could possibly get around using the shadow registers if you pushed bc (you could maybe move the push bc before the ld bc,288 to the vbcx3Row label), opening up C to use instead of D for the gbuf byte to rotate, then you could use DE to hold the pointer to the palette array. The palette array just tells you the first palette value, eg. 0 corresponds to palette entries 0 and 1, 1 corresponds to 2 and 3, 2 corresponds to 4 and 5, etc. That'd look something like:
        ; bit 7
        ld a,(de) ;de points to palette array
        sla c \ adc a,aThe overhead would be a bit less than my first idea, i think. Each tile would still only have two colors, but the map would be a bit more colorful. You'd also have to fill out the palette array as you draw your tilemap, but that shouldn't take up too much time. Definitely wish i had a CE right about now

EDIT: And if you come up with something that's too processor heavy, there's always shifting two pixels per frame which would still look really nice.