Sunday, November 05, 2006

XeO3: Another day, another feature....

I've been playing with the sprite routine again last night, and came up with a nice little feature that I'll use when baddies are shot. As you can see the sprites now turn completely single colour and flash when they get struck. On the C64 something this is pretty easy to do since each sprite has its own colour, so you can just flash that - but when drawing software sprites, its not as simple - this is in fact a whole new sprite! Or is it.... All I do for this is to use an inverse of the AUTOMASK and ORA the data into the display. The automask if you'll recall is a way of automatically masking MCM pixel data, and given any sprite the automask works out the data needed to MASK it on - so invert that, and you have your FLAT sprite.

Like everything, its not without its expense. It costs around 200 bytes for the code, and is slightly slower (when a sprite is over space) than normal. But it only happens every now and then, and being able to tell you've hit something is great, particually on baddies that take plently of wallop - or ones with limited collision areas - like a BOSS or something.

I also had to get Luca to swap all the colours to make use of it as it must use colour bits %11 or I have to AND as well.... Still, its a neat little touch so we'll probably try and keep it in.

Its also that time again, and I have to go hunting for memory once more. I've decided to rewrite yet more areas of the sprite routine - mainly the data structures as this should save around 2k overall - quite a saving. But theres a lot of work involved; I'm going to replace the cache pointers with a cache index (and a small table). Also, due to the way I move sprites up and down, I have 8 bytes at the start of every cache block to allow for a sprite to move down (I move the draw pointer up 1, the sprite gets drawn down 1 pixel mode), and because these are located directly beside the cache info, I have to repeat these 8 bytes all the time. However, if I split up the INFO structs, and the DATA itself, I can store 8 bytes at the start, and then remove all the others - again, a small table will probably suffice.

7 comments:

Chicken said...

It's hard to judge by a static screen shot. Maybe Luca can create (as if he wouldn't have more important things to do) a small mock up animation ;) So flashing means switching between single color (white in the example) and all colors (normal sprite look)?

Mike said...

Don't worry....Its obvious when its playing. I wasn't sure if I was going to keep it, but Luca loves it, so it has to stay! :)

Chicken said...

That's cool :) I trust Luca on that one ;)

I just played Xenon II on gameboy and the end of level baddies flash, too (maybe a bit different, though). I think it's a good "feedback" for the player. But I'm more curious about explosions and accompanying SFX :)

luca said...

Well, the explosion sprite had been shown everywhere in the xeo3.org, so...
About big bosses: flashing is great, coz it can occur only when the weak point has been hit!

XeO3-CPC said...

This is so cool, the Retro scene is just going from strength to strength.

Don't think we can let you Commodore and Speccy guys have all the fun with this game though. ;)

luca said...

AndyC:ah, a CPC version too! :D And who's on Atari800XL? And MSX? Vic20? Mmmm...BBC?
Anyway, set the comments free or other/anonymous users too... ;)

Algarbian said...

"And who's on Atari800XL? And MSX? Vic20? Mmmm...BBC?"

A Sam coupé port would be nice too! dragon 32/64? Tandy Coco? Thompson?

don't worry guys just dreamin' lol