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.

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.

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.

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.

Monthaversary!

Well, it's been a month since I started... when I put it in that perspective I've done quite a bit. From rebuilding the computer, finding docs and programs, to having a decent system friendly setup, scrolling background, a fair bit of graphics work done, as well as the main sprite moving, animated, and firing.

There's still a lot to go, but it's starting to come together into something that may become a half-decent game.

I managed to get a full printout of the devpac manual and have been pouring over it the last few days - reremembering bits and peices like setting up proper macros. Rebuilt a few of mine, as well as getting the whole startup code to work with the include files a bit better.

I also came across a nifty directive: rs. and rsreset.

Basically rather than declaring a block of space, it just gives you an offset, which may sound a little useless (why get that when you can just declare the space and be done with it?) - but is REALLY useful. Since leaving the Amiga I've gone on to learn other things, and other styles - such as C, whose data structures are REALLY useful. RS gives you a way to do that in Amiga assembly.

If each lable past RSRESET gives an offset, you can use it to address indirectly, and if you have an RS with a value of 0, you can calculate the size of the whole - which means I can write just ONE structure for bullets, declare the space for each, then with a single routine, manipulate all of them by just changing the base address.

It's one of those things where you'll either read it and say 'Oh yeah!' or you'll say 'huh?'.... and no amount of explaining will change it..

Anyways - the upshot is that I've been rewriting all my buggy, bullet, and movement routines to use this - it's actually brought the code size down considerably - and each time I find myself re-writing the same code I look to my object structures and say 'what can I add to make this more modular?'

Lots to do over the next month - the main focus will now be on objects like craters and rocks, bullet collision and minor tweaks to movement, firing, and special effects...

Cheers.

Another step forward..

No fancy screenshots today - it's nearly 7am and I have to start getting ready for work in another half hour or so... enough time to type some rubbish, listen to a few more mod files and have another coffee.

Progress is coming a little more quickly now - not sure if it's me getting back into the swing, or that enough of the 'machine level' routine are enough in place. Either way, converting the buggy from a straight 'copy blit' to a 'cookie cutter' blit that leaves background intact - setting up the initial horizontal rocket and getting it firing, moving, and resetting was all done between the hours of 3am and 6am this morning.

A strange time, but it's working for me. I've hooked up with a group of folks that want to write new games for the Ami at Underground Arcade. I'm hoping maybe I can get some help when the time comes. I'll keep and eye there and post game updates etc, hopefully they'll be a motivating factor (or me on them) - Even 'back in the day' it was rare to see anyone muster the dedication for the long haul (myself included... grand plans that never reached fruition). But it doesn't hurt to try - the worst that happens is I continue alone.
Anyways, the topic of 'not enough time' came up in reference to coding - as I said 'you have to MAKE time for it', as I get older time becomes less available. Getting up at 3-4am is working at the moment, gives me time to wake up before work too.

Anyways - time to re-fill the coffee and think about the day ahead.

cheers!

Motivation

Somedays willpower simply isn't enough.....

It's not that easy being a one-man dev team on 20 year old hardware.  Although if you can write a basic scrolly demo - you have 90% of the technical skills to write a game.. The killer is the scale.
That's what sucks about taking the step into a dark tunnel - knowing you have many more steps before you see the light.

If noone goes first, noone will follow... Doesn't even mean my game has to be good - if it sucks I can say 'well -- at least I finished it....' and maybe someone will get pissy enough to do something better.  While they wait for someone else to go first... the platform is slowly dying.  Which is a shame.

So you work in vaccuum pretty much - you don't want to tell the community your working on something - because you won't please EVERYONE no matter what you do, and if you just give up like everyone else, you become on of those false promises..... no..... much better to work in silence until something is done.

Lucky for me - others do the same thing in their own way.  During my vacation there were a few days of wondering if I'm just wasting my time.  The answer eventually presented itself more eloquently than I could put it:



Thanks Eric.

Buggy Blitting

Ahhhh back at work again - after a nice 'stay-cation' of a week, the first in 2 years - I'm nearly glad to be back.  Backwards as it sounds, development time should INCREASE now that I'm back at work.

Spending an hour or two after the stresses of work to 'wind down' is quite acceptable... spending 12 - 18 hours locked in 'the manfort' isn't.... besides, timing my vacation to coincide with my birthday (42) and my wedding anniversary (11) sort of took care of a lot of the 'spare time' I'd have on my hands.

So - buggy blitting.. most my coding time was spent re-aquainting myself with the blitter.  It's little quirks (being one of the first of it's kind - it's allowed to have some) like it only blitting to short word (2 byte) boundries, and the barrel shifting needed to make pixel adjustments are in the very top 4 bits of it's control register....  while the math to pull round the address and pull the pixel offset is in th every BOTTOM 4 bits of an 'x-coordinate'... that all screen offsets and modulos are given in BYTES and all blitter start locations are on WORD boundries...  lots of little problems to scratch your head over - none of them huge - but each one time consuming.

Anyways - we now have buggy motion forward and back - linear at the moment - and the background scrolls accordingly... speeding up and slowing down as needed.

Starting to look more like a game now!