Author
Topic: Alien Breed 5 Episode III: Impact (Read 5530 times)

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

Great work as always! Can't wait to see what comes out of this? Are you planning to release a tutorial/the source for your mono-to-color method at some point?

Certainly the code and details and implementation will be released - it's actually quite simple. The tiles/sprites are just drawn to a 768 byte buffer as they would be on the non-colour calcs, then it's just a special routine to scale this up either x2 or x3 as it simultaneously writes it to LCD memory.

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

Partial redraw? I'm only writing as much data to the LCD as required each frame, which is either 3072 bytes (192*128/8) for the x2 zoom or 6912 bytes (288*192/8) for the x3 zoom (remembering that the LCD is in 1bpp mode to resemble the non-colour calcs). Or does the 84+CE have some kind of interlacing method like the CSE that I've missed in the documentation?

Hey James, this is pretty awesome. Honestly, it doesn't look too bad at 3x resolution speed wise. I wonder what the bottle neck is though since the processor is a lot faster?

The bottle neck is probably just my inefficient routine that I put together in a rush

After sleeping on it, I came up with a different method this morning for copying & scaling the video buffer more efficiently. I only had a chance to test it on the 3x zoom (288x192 resolution) and it was running at pretty much the same frame rate as the 83+/84+ non CE version. I'll try it later on 2x zoom as well and see how fast it gets, but at a rough calculation it should be about 30% faster than the 83+/84+ non CE frame rate.

Today I've finished off (for the time being) the new level event scripting that will feature in Episode III: Impact (and Episodes I & II will be patched to the new format as well). The new format gives me more power to add multiple triggers & events during a level. In the below screenshot there are a few examples:

1. After a certain amount of time passes, an in-level text block is displayed, and the darkness filter is enabled.2. When the player walks up to the computer, another text is displayed and the darkness filter is disabled.3. Bosses are no longer triggered by a single tile - an area is set (can be any rectangular shape up to 32x32 tiles in size) that triggers a boss (technically there could be multiple bosses in a level now), and in this case also modifies two tiles in the level to seal off the room (previously this was locked to modify one tile when a boss fight started, and one more tile when a boss fight finished).4. When the boss is killed, multiple tiles are modified to open various paths out of the room, the countdown sequence is triggered, and the level is flagged as being ready for completion.

Triggers & commands can be used in various combinations to create various events so that I can add more depth to the new levels.

Now that this is done, I'm going to attempt to start adapting the code and applying the new LCD routines to make it compatible with the TI-84+CE

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!

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 exxld 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 7ld 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.