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:...

Your ability to design games is undoubtedly unquestionable, period! (+1)However the z80 reminds me of my old student times, more than 30 years ago (sorry 'bout that). What to do you guys find in phosphorus green/yellow so passionate, if I may ask ?

8bpp is faster, the issue is that the original routines are written for the BW calcs so all sprite routines are drawn to a graphbuffer that has a 1bpp layout. Writing to a gbuf on the CE just makes it easier to maintain the code between the two calcs, otherwise you'd have to have separate code for the tilemaps and basically anything that interacts with the map (sprites, bullets, etc.). So (i assume) James just uses the same routines to scroll the tilemap.

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.

These are some interesting ideas, chickendude. Thanks for the suggestions! At this stage I'll simply focus on getting the game playable on the 84+CE for starters, but you're giving some great inspiration to strive for greater results with this in the longterm!

8bpp is faster, the issue is that the original routines are written for the BW calcs so all sprite routines are drawn to a graphbuffer that has a 1bpp layout. Writing to a gbuf on the CE just makes it easier to maintain the code between the two calcs, otherwise you'd have to have separate code for the tilemaps and basically anything that interacts with the map (sprites, bullets, etc.). So (i assume) James just uses the same routines to scroll the tilemap.

Correct, the 84+CE version uses all the same sprite drawing & scrolling routines - the only difference (at this stage) is copying the "gbuf" to the LCD, which on the 84+CE converts the 1bpp data to 8bpp and scales up 3x. The main reason for sticking with the 1bpp "gbuf" is to keep the speed of the scrolling/sprite & tile drawing routines as fast as possible.

I haven't done much work on this for the past week as I've been enjoying a summer week off work, but current status is that after many hours of work, the source now cross-compiles for both the 83+/84+ app version and the 84+CE program version. Now I just need to start stepping through the 84+CE version and get the game to a playable state.

I'm getting close to getting the game somewhat playable on the 84+CE, there are just a lot of little Z80 -> eZ80 things to patch up (eg. "ld h,0 \ ld l,a" needing to be updated to "ld hl,0 \ ld l,a" etc.)

In terms of the new campaign, Episode III: Impact, it will be a little different to Episodes I & II. Instead of just being a linear 12 level campaign, it will have multiple routes available. The current plan is to have around 30 levels, with a single play through taking you through anywhere between 11-14 levels depending on the path you take (around 5-6 different paths available). The paths that take less levels will have a slightly higher difficulty curve than the paths that take more levels. This one won't be set on a space station either, it will be on a planet surface & multiple towers, ala Alien Breed: Tower Assault.

I've also got at least one more enemy getting added in (the "security guard" enemy from the previous Alien Breed IV game of the early 2000's that I did), and I have ideas for another 2 possible enemies that I haven't implemented before that I think would be cool

The game now runs and the player can move around a level. Enemies / shooting, etc. are still disabled, but should be working in the next week or two. I haven't had a whole lot of spare time to work on this lately, but I'm enjoying chipping away at it bit by bit

Text & menus aren't properly implemented yet, but I'll (most likely) be overhauling them on the TI-84+CE version to have higher definition splash screens and font.

Correct, there will be a flash application version for the TI-83+/84+ monochrome LCD calculators, and a program version for the TI-84+CE calculator. Both will be the same game with the same features, with the exception of the TI-84+CE version having bits of colour here and there. And yes, it does run a lot smooth / nicer on the TI-84+CE screen

Do it! I couldn't play Robot Wars on my TI-84+ because my RAM chip is only 24KB, but if I get a CE next, and you port this, I could play it instead of looking at the beautiful title screen, without the ability to start a new game.

Wow, at first i thought that was a screenshot of the 83+ version, it does run much smoother/faster on the CE. That's exciting, i'd like to take a stab at porting some of my old projects over to the CE

It's not super hard, just depends how much "hardware dependent" code you have (such as accessing port $10 on the 83+, etc.) and also accounting for the 24-bit multi-registers. I'm happy to send you my gbuf -> LCD drawing & scaling routine if you need it