Double dat buffer!

I'm excused for being a little remiss in my dev diary. Things are getting done, life marches forward.
I've been spending a lot of my time at work lately backing up files / projects / file footage because my entire edit system was being replaced. For anyone interested I've gone from using an Avid Adrenaline to an Avid Nitris Symphony. The big difference between the systems is a much expanded capacity for the ability to do High Definition video editing, and I'm enjoying the 9Terabyte storage :)

For those not interested (well you read through that already so too bad!) - suffice to say I've been VERY busy both at work and studying out of work for the transition.

In the big, mind numbing, whirlwind of the last two weeks I'd forgotten something I was going to add to EVA but had slipped my mind:

Double buffering the display screen (it's dual playfield display - so the front only needs it). I found this out while writing the jump code algorithm. As the buggy hit it's apex the top would be cut off.

I tweaked around and found the problem was pretty localized - my map code was still in testing so you had 4 rocks, the buggy, 2 bullets, rock explosions - all having backgrounds buffered, being drawn, being cleared - the bullets were doing a no-destination blit when they passed into the bounding box of the rocks.... and in this stress test when the buggy was being drawn high on the screen (the LAST thing to be drawn) it was being drawn above a point that the scanline (drawing the screen) had passed. Because after each game loop it waits for the vertical blank - then ERASES the old graphics before redrawing, the top of the buggy would never be redrawn.

So, double buffering - I keep 2 foreground screens in memory, draw to a back screen - wait for the vertical blank, swap back screen to the front.... erase the old graphics and draw again.

It's a memory overhead, but a necessary one - and at 320 x 200 pixels and 3 planes only, not a HUGE one.

The upside is knowing exactly how my code is running.... I'm doing an 8 level paralax scroll, blitting with mask and background merge over 10 blitter objects, doing both math AND blitter based collision detection on several objects - as well as any updating overhead for this... in the time it takes the beam to travel down 30 lines of the screen......50 times a second.

All in all - I'm rather pleased with the code... it could be optimized, of this there isn't any doubt, but at this point I've done around 70 percent of the 'hard grunty coding' - and only using around a fifth of the time afforded me to still run at full frame rate. So for now I'll go with robust easy to read code over optimization until I have to.

This week I'm putting ALL projects on hold until I rewrite all drawing routines to use double buffering (now I'm REALLY happy about changing all those drawing routines last week!)

Cheers

Sig.