Well I'd like to say I'd been fighting the good fight, fixing lots of little things and taking care of business.
Alas - this is not the case. Work, family, other obligations cut down my 'computer time' to so little that it hasn't been worthwhile to switch on and sit down most days.
This is one of the busiest times of the year for me, so everything needs to take a back seat. Summer is on it's way and bringing the blistering heat that has destroyed more than one of my PC's over the years, and so Amiga programming will have to be done in the relative cool of the evening.
Some things have been worked on, several things have been tweaked slightly - all the blitter collision routines have been written - and implimented for the bullet vs rock collisions. Some graphics have been worked on in my spare time, and various linked list routines have been updated since my re-reading of Amiga System Programmers guide. There is a limit to what I can rewrite though - so some concepts will have to be implimented at the ground level next game.
EVA is still very much alive, although this months progress has been less than stellar.
Tuesday, June 3, 2008
Monday, May 12, 2008
Month 2
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.
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 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.
Wednesday, April 30, 2008
Bugs bug me
No sooner had I thought I'd put the rock code 'to bed' for now, I noticed something slightly out of place.
I was running a quick test of the map code (to start on craters) and noticed a graphics glitch - I'd forgot to replace the error check at the end and it was seeing the new map-code as another rock.
Also, there were only 3 rocks on screen at once... not 4 as there should be. I'd realized with some playing that it would be WAY too difficult to shoot down 4 anyways - so hadn't given it much thought past that... nope something was amiss.
Part of me by this stage is saying 'well - it works with 3... that's good enough.. just don't put 4 in the map close together! - problem solved!'.. But I knew that 1) this would sit in the back of my head and annoy me - and 2) EVA isn't so much about 'getting a game done' - it's about solving a specific set of problems with robust and modular code I can use in future project.
If I was trying to just get it working and that was that I would just set them up 'manually' and blit them - done.... instead I've borrowed concepts I've learned in my time away from the Amiga and assembly programming in C and other languages.
Each graphic in EVA has it's info placed in a memory structure (just like a C struct - see below about RS directive and addressing modes) - every graphic, be it a block, a bullet, the buggy - all contains info about how it's to be drawn, it's size, etc. Each structure has the ability to be expanded with specific info to further define it if needed - while retaining all the original info shared by all graphic objects (an oversimplified version of inheritance you find in C++ and other languages).
Further - all are grouped into linked lists. Each graphic element contains a pointer to the next element in it's series. Somewhere this wasn't working as it should.
It brings up the question that I was asked a lot back when all my friends were making demos, 'why? why not just blit it and be done?'
Well, it makes several things possible - automation being one of them, I can feed the address of say, the top level bullet into my draw routine and have it animate and draw ALL them - by simply passing ONE address.
Clarity in code - each routine does one thing, and does it well (or as good as I can make it), and each routine is named for what it does - concepts I learned from UNIX. As you work up from the machine level basics, the code becomes easier to read - 'fetch_next' 'draw_object' 'update_rocks' - each of these routines contains others that break it further, until you hit the bottom line at the machine level - where it's 90% moving to registers and other things. Things learned from programming MOO's and other online games.
Scalability. As it stood a week ago in the 'get it working' stage - to add just a single rock element required changes to 7 different bits of code..... setup, initializing, drawing, clearing, updating,collision detection, and of course allocating memory. Now it only needs one - setup.
Setup creates X amount of objects of that type and links them - every other routine automatically runs down the list - updating what needs updating, drawing what needs drawing, doing collision checks where needed.
And of course - portability. All the graphics routines could be lifted in a single file and used in the next game, and all I'd need do is draw new graphics and fill in the setup data. All basic animation, drawing, moving, etc.
Eventually I found my bug - and fixed it - a mistake in when I was checking for the end of the list... I guess another bonus in taking the long road was that the error itself told me where to look, and although it took me some time to work out what I'd done wrong - it was all fixed by changing just 3 lines of code.
Guess there's some benefit to taking the road less travelled. One of them being that I shouldn't have to travel down it again for some time.
I was running a quick test of the map code (to start on craters) and noticed a graphics glitch - I'd forgot to replace the error check at the end and it was seeing the new map-code as another rock.
Also, there were only 3 rocks on screen at once... not 4 as there should be. I'd realized with some playing that it would be WAY too difficult to shoot down 4 anyways - so hadn't given it much thought past that... nope something was amiss.
Part of me by this stage is saying 'well - it works with 3... that's good enough.. just don't put 4 in the map close together! - problem solved!'.. But I knew that 1) this would sit in the back of my head and annoy me - and 2) EVA isn't so much about 'getting a game done' - it's about solving a specific set of problems with robust and modular code I can use in future project.
If I was trying to just get it working and that was that I would just set them up 'manually' and blit them - done.... instead I've borrowed concepts I've learned in my time away from the Amiga and assembly programming in C and other languages.
Each graphic in EVA has it's info placed in a memory structure (just like a C struct - see below about RS directive and addressing modes) - every graphic, be it a block, a bullet, the buggy - all contains info about how it's to be drawn, it's size, etc. Each structure has the ability to be expanded with specific info to further define it if needed - while retaining all the original info shared by all graphic objects (an oversimplified version of inheritance you find in C++ and other languages).
Further - all are grouped into linked lists. Each graphic element contains a pointer to the next element in it's series. Somewhere this wasn't working as it should.
It brings up the question that I was asked a lot back when all my friends were making demos, 'why? why not just blit it and be done?'
Well, it makes several things possible - automation being one of them, I can feed the address of say, the top level bullet into my draw routine and have it animate and draw ALL them - by simply passing ONE address.
Clarity in code - each routine does one thing, and does it well (or as good as I can make it), and each routine is named for what it does - concepts I learned from UNIX. As you work up from the machine level basics, the code becomes easier to read - 'fetch_next' 'draw_object' 'update_rocks' - each of these routines contains others that break it further, until you hit the bottom line at the machine level - where it's 90% moving to registers and other things. Things learned from programming MOO's and other online games.
Scalability. As it stood a week ago in the 'get it working' stage - to add just a single rock element required changes to 7 different bits of code..... setup, initializing, drawing, clearing, updating,collision detection, and of course allocating memory. Now it only needs one - setup.
Setup creates X amount of objects of that type and links them - every other routine automatically runs down the list - updating what needs updating, drawing what needs drawing, doing collision checks where needed.
And of course - portability. All the graphics routines could be lifted in a single file and used in the next game, and all I'd need do is draw new graphics and fill in the setup data. All basic animation, drawing, moving, etc.
Eventually I found my bug - and fixed it - a mistake in when I was checking for the end of the list... I guess another bonus in taking the long road was that the error itself told me where to look, and although it took me some time to work out what I'd done wrong - it was all fixed by changing just 3 lines of code.
Guess there's some benefit to taking the road less travelled. One of them being that I shouldn't have to travel down it again for some time.
Sunday, April 27, 2008
Rockin'
Finally caught up the code I lost, and managed to get some time in between work and home to get to the next milestone. A simple level map puts different sized rocks on the screen which change size as they're blasted with the missiles.
The scoreboard still doesn't update - mainly because it's still not 'set in stone' - and I'm not 100% happy with the look or layout.
It's starting to look more like a game, with very basic playability.
Time can be spent now tweaking the buggy movement - rate of increase on the scrolling background, and acceleration of the buggy.
I've never liked the jerky stop-start that a lot of games had on their main sprite. I'll be working on some code that does a subtle speed up and slow down.
Jumping can now be added, and later craters. Collision detection for the main buggy still needs adding, and missile to rock collision is still only a math check on the bounding box.. when the buggy can jump, another level of detection using a mask will have to be added.
Sunday, April 20, 2008
Disaster Strikes
Not a HUGE disaster - but a big setback nonetheless.
2 days ago the hard drive on the 2000 gave up the ghost. Luckily I backup the entire thing every weekend - so I only lost a couple of days of work.
I'd just managed to get another Harddrive and was hoping to run them both, so now I've been spending the last couple of days installing it, getting it running, and slowly getting things installed and back up to speed.
Coding should continue tonight, or tomorrow - although real life commitments will make getting much more than replacing work already done hard over the next week.
Sig.
2 days ago the hard drive on the 2000 gave up the ghost. Luckily I backup the entire thing every weekend - so I only lost a couple of days of work.
I'd just managed to get another Harddrive and was hoping to run them both, so now I've been spending the last couple of days installing it, getting it running, and slowly getting things installed and back up to speed.
Coding should continue tonight, or tomorrow - although real life commitments will make getting much more than replacing work already done hard over the next week.
Sig.
Tuesday, April 15, 2008
Taking the backseat.
Just as you think you're hitting a routine, life throws you a curve ball it seems.
No sooner had I been basking in the glory of a month of steady coding and re-learning, I hit a speed bump. My work - real work - the one that pays the rent - has been rather lazy lately - affording me a good amount of time for reading up on things, thinking things over, etc. Not that I'm sitting doing nothing - just not flat out busy.
Things are a-changing for the next few months with several projects landing on my desk with quick turnaround times. By the time I get home I'll be pretty much mentally spent, and needed to have my head in the right place by the next morning. This is the problem with jobs that rely on a fair amount of creativity... you have to bring it every day - and if it's not in you that day, you have to force it out. This doesn't leave a LOT left over for thinking about code by the end of the day.
EVA will have to take a backseat for a week or so while I sort this out. This doesn't mean I won't be working on it at all - only not with the regularity I have been.... still there's a LOT of little tweaks I can work on in the meantime - and leave the major code till later.
Still no screenshots (I'll save that till the end of the week when hopefully more visible progress is made) - but last night I got some of the bugs out of my first-pass collision detection for bullets and put up a 'test rock' to shoot at.
It's not perfect - but it's working. Progress is made. Life goes on.
No sooner had I been basking in the glory of a month of steady coding and re-learning, I hit a speed bump. My work - real work - the one that pays the rent - has been rather lazy lately - affording me a good amount of time for reading up on things, thinking things over, etc. Not that I'm sitting doing nothing - just not flat out busy.
Things are a-changing for the next few months with several projects landing on my desk with quick turnaround times. By the time I get home I'll be pretty much mentally spent, and needed to have my head in the right place by the next morning. This is the problem with jobs that rely on a fair amount of creativity... you have to bring it every day - and if it's not in you that day, you have to force it out. This doesn't leave a LOT left over for thinking about code by the end of the day.
EVA will have to take a backseat for a week or so while I sort this out. This doesn't mean I won't be working on it at all - only not with the regularity I have been.... still there's a LOT of little tweaks I can work on in the meantime - and leave the major code till later.
Still no screenshots (I'll save that till the end of the week when hopefully more visible progress is made) - but last night I got some of the bugs out of my first-pass collision detection for bullets and put up a 'test rock' to shoot at.
It's not perfect - but it's working. Progress is made. Life goes on.
Subscribe to:
Posts (Atom)