C64 :: Bump and grind

After a busy day pretending to be a writer, i like to relax and have a quiet evening discussing buffer selection with my collision routines... [Sits with smoking jacket in big leather armchair, with laptop and pipe that, when blown, produces soap bubbles for comic effect]

And after a bit of an altercation which i initially lost, they now take into account which of the two display buffers is in the foreground when attempting to read what is underneath the ship! That's a major plus, the whole thing was pretty unpredictable when, for eight frames out of sixteen, it was reading the damned back buffer during the redraw so it was picking up all sorts of odd ideas! i also spent half an hour tweaking the collision area, getting it lined up closer to the centre of the ship; it's a pretty rough calculation, but if it's good enough for the likes of Armalyte or Io, it's good enough for me too and now it's about as accurate as things get i'm happy.

i've also had the chance for a quick prod around the object decommissioning system and, after a little tweaking to get it working in a way that wouldn't limit the top vertical motion speed of the objects, it can spot something going out of bounds vertically as well as horizontally now; to be honest this isn't really needed for Charge Armada but i have a few other projects that i want to reuse parts of the object system for in the early stages, they could do with that feature so, since it's a fairly minimal overhead, it went in now to save me having to remember later...

C64 :: Testing 1, 2, 27?

Well, had a busy Sunday but at least got a few things done that i wanted to; the first previews of Charge Armada were sent to the people doing level designs so that they can see what their tiles and characters look like in place. i'm a little tired, but hopefully i didn't stuff up any of the colour data during tile conversion! Generally speaking, it's starting to look pretty cool with the backgrounds going past and sprites whizzing around. The code has some documented "features" in the collision system and a few other foibles that i need to iron out, but generally speaking things are going well.

Note to self; when deciding to give a set of routines a silly name like Alien Release Scheduling Engine, it's important to remember that you'll be doing ARSE double entendres for quite a while afterwards...!

PC :: Oops, sidetracked!

Spent part of today working out how to produce something similar to the alien release scheduling engine (or A.R.S.E. for short... you should see some of the comments in my source!) from Charge Armada in Blitz Max and, generally speaking, things went pretty well; i now have a similar scripting language, but with up to thirty two moves per nasty (the C64 version only has eight), each object contains a unique set of commands rather than having the wave data and object move data seperate and all the movement stuff is optimised in that i can terminate a move sequence and wrap to the start early. In fact, the only thing it hasn't either got or improved upon is the death inheritance system that CA has, that's partly because explosions are handled independently to the nasty object system on the PC and partly due to the new format for the object data but i'm considering ways to add it if the need is there...

i haven't entirely decided what to actually do with the engine yet, but there's always the ShmupDev rapid prototyping "compo" perhaps... how to make a shoot 'em up where the ship can't fire, i wonder!

C64 :: Hmm, upgrades

Today (well okay, yesterday to be strictly accurate) saw me taking out a lump of the nasty movement handling code and rewriting it to double the horizontal resolution; usually i just deal with values of $00 to $ff for horizontal sprite positions and multiply everything by two to save having to piddle around with the most significant bit, but this new game was getting to the point where it needed at least some objects to be able to track along with the landscape so a bit of surgery was required... eventually the damned thing worked as well, at least it did after a lot of fairly creative swearing and a second re-write to get the overheads down. Now the only serious bit of CPU grind from the object handling is when it nips off to pull up a new baddie. i'm not sure at the moment why it's got such a large CPU requirement but i can hazard a few guesses; it copies 32 bytes per nasty then re-assigns some of those around to other places... so it might be time to see if i can't consolidate those data tables into one affordable loan place in memory.

The other news is that i'm finally starting to settle on a name; this process usually takes a while, bouncing words around and seeing which sound best when put together. After a little mental juggling, the most probable candidate for this game is Charge Armada.

C64 :: Blam, blam, blam!

Today saw me spending a couple of hours dropping some test data into the new project and it lives! Well okay, it was already living but now the aliens look like aliens, the player's ship looks like the one from my own game Warflame (because that's where it's from!) and it currently fires copies of itself at the aliens because the bullet system is going to be re-written soon to use a different system so there's no point in me adding a sprite definition for the moment. There were a few hiccups where the objects weren't being decommissioned properly and explosions were getting "stuck" on the screen until the management system needed to recycle that particular sprite but after that it looks rather spiffy.

Today's other job is probably going to be getting a character set ready for the status panel and starting to get the splitting system in that masks the sprites if they arrive or leave the play area from the bottom - the object decommissioning checks could do with being expanded to remove objects that get too far out of the screen boundary vertically (this already happens horizontally) so i'll probably add that as well and i've yet to do the cosmetic stuff like make aliens strobe white for a frame when shot. There's still a long way to go, but it's looking pretty solid so far...

C64 :: Ongoing project

i've decided to keep a development blog! i'm not entirely sure why i decided to, but it seemed like a good idea yesterday so here it is! My active projects tend to dot around quite a bit (something i'm attempting to keep under control with a relatively low degree of success), so there's a good chance this blog'll do the same but the more general waffling (at least after this general waffling) will mostly be reserved for my main blog. i'm going to prefix entries with a format and i might do something fun with the syndication to allow filtering for specific machines... if i get time.

So my ongoing C64 shoot 'em up... the name is almost settled and it's current status is that it scrolls 22 lines of the screen with 4x4 character tiles, has colour-per-tile colour scroll and at the moment only uses eight sprites; one for the player, one for a bullet and six for the nasties. The engine is being kept "generic" for the moment because, once i have the attack wave managers absolutely the way i want the things, i plan to "fork" the source off for a couple of other projects. Cheaty i know, but i don't usually rely on library source so it might be a good idea for me to start.

Yesterday saw a fairly major overhaul to the nasty object control stuff; after four or five hours rewriting large blocks of the existing code and swearing (planning ahead... something i've never been much cop at! =-) the objects have eight moves (previously it was just two) which are specified as speeds for X and Y and a duration. They can also be shielded and have the option to "mutate" into another object or simply explode when destroyed, which adds a lot of interesting possibilities... there aren't any real objects defined yet (because there aren't any sprites ready to install) but everything seems to be behaving so that's a small victory!