It's officially 2 months into the project. 2 of 12 - 10 to go.
Over the weekend I sorted out the double buffering routines, and updated everything to run with it - there are a few tweaks here and there to get everything running and drawing the way it all should, but I'll get those sorted out over the next week.
I've not put an updated demo on Underground Arcade for a while, if I did it would look pretty much exactly the same - and I'd find myself throwing more rushed code in to make it 'look different' - something I don't want to do anymore.
The jump code was started, but needs some fine tuning, and buggy controls in general need to be fine tuned. The devil is always in the details. I do think it looks strange with it's wheels spinning in mid-air, which lead me to changing the animation while it jumps.
Currently the animation system works pretty well, even the 'cludge' I've thrown in for the rocks changing size when hit - adding multiple animations for each object is something I should have added in earlier, but sort of rushed past in order to get something to show. This week will be spent going over the animation system yet again to make it more flexible, and hopefully faster.
So again, lots of coding going on and if all goes well by the end of the week I should have most of these things knocked out - and of course the end result, if all goes well, will look EXACTLY as it does this week!
Seeing something on the screen working is always motivating - but having to go back and wade through rubbish code and re-write everything is totally UNmotivating. It's not like hundreds of people are looking at the in-progress demo anyway. Maybe 3 total. I'm more than happy to fly under the radar and get things done the way I want them.
In the end I have to just do this for myself - and noone else.
Monday, May 12, 2008
Monday, May 5, 2008
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.
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.
Subscribe to:
Posts (Atom)