A8 :: shooty stuff

i've been thinking about writing a shoot 'em up for the Atari 8-bit for literally years now... but it's not the easiest machine to write that kind of game for. The current project started as something of a urine extraction of a particular person at Atari Age who rather ridiculously kept banging on about how more colours in a game somehow made it more beautiful. No, i couldn't see it either so i threw together something with three playfield colour splits a scanline that essentially looked like Rainbow Brite had vomited down the inside of the monitor to demonstrate:



i suspect a few people thought that was just a mock-up when i posted it (and it keeps getting complements, that's worrying...) but there's a fully functioning game engine behind that too... but the sprite engine being used isn't much more complicated than what games like Mirax Force or Humanoid already do (it has some wave sequencing behind it so there's more game logic going on, but the way it actually recycles hardware sprites is the same) so everything is on horizontal rails. It's workable, but seriously limited when it comes to what the nasties can actually do.

So i started thinking about other options and now i have a [i]second[/i] preview, this time far less busy on the playfield colour splits but changing the sprite colours every other scanline and able to recycle the three sprites assigned to nasties (the player's is dedicated) in order to give six relatively free standing objects whizzing around the play area with a more complex wave sequencing engine feeding them control data. Fantastic stuff and i can live with just one of the playfield colours being split... except to my mind the sprites simply don't look as good with one colour and splits (the splits are a scanline out on this screenshot, use your imaginations!):



So now i have something of a dilemma, do i go with this revised engine and carry on, look at the possibilities of changing it again to multiplex three colour objects (if i do, the player's ship becomes a software sprite and things are... fraught as far as available CPU grind go already) or is there a third option...

Decisions, decisions...

In the meantime, i might arse around with the scroll engine and multiplex to produce a much simpler game to see how things stand on CPU loads.

C64 :: GR9 Strike Force released

It's being called the "party version", but GR9 Strike Force has been released over on the Cosine website. Yay! Here's a screenshot from the final release:



Enjoy...

C64 :: so near...!

GR9 Strike Force is pretty much done bar the pretties now... here's the video!

C64 :: bugs and tanks

The code that manages the likkle tanks went into GR9 Strike Force yesterday (for speed, the various objects are driven by discrete blocks of code rather than a generic management routine) along with a first draft of their firing routines; at first everything seemed happy bunnies and they'd tootle into the play area, stop after a distance set by the wave data and began firing, exactly what they're meant to do until something odd started happening...

It took about three damned hours to diagnose, but the symptom was that Tank 1 would drive into play from the bottom of the screen, park up and start shooting normally. Then the attack wave manager would throw a couple of passing aircraft into the mix before getting to the data for Tank 2. Just after Tank 2 was assigned (using up the last available object) Tank 1 wanted to fire and couldn't find a free object for it's bullet. The routine has a contingency which essentially suppresses the urge and resets the counter as though the shot happened... but it'd mangle one of the registers on the way out (it should've recovered it from a storage location, but the command got lost in the wash) with the result being that the attempted bullet firing dented a table of timers so Tank 1 forgot it was in "stopped and firing" mode and promptly drove away!

Silly likkle tank.

C64 :: Whoosh!!

Here's a screenshot taken about thirty minutes ago with some "real" attack wave data in place and the status bar pretty much working as it's meant but on test pictures - there's also a video to see it moving on YouTube:

C64 :: GR9 under way

Okeydokey, so i posted to Facebook, uploaded video to YouTube and mentioned it on a couple of forums whilst forgetting my own dev blog... the new C64 project is under way and called GR9 Strike Force; it's another horizontally scrolling shoot 'em up, being written for Retro Reunited and the overall theme is more current than most of my previous games. According to the finite "research" i did, the GR9 Harrier is the model in service with at least some of our military right now.

Here's that video i uploaded:



The status bar has been drawn and installed, along with a six by six character area for a digitised picture - the idea is that at the event someone'll win a door prize, be photographed making themselves look a plum and be inserted into the game as an avatar during play and on the loading screen "live". Today was spent writing a very specific converter that takes four blocks of 24 by 48 multicolour pixels and converts them into a six by four character block in the status font, two sprites with the extra sixteen pixels that are in the lower border and six high-res sprites that are horizontally expanded and used as overlays to give a total of six colours for the image.

And yes, the code running in the video already has the upper and lower borders open and is handling the masking as sprites leave vertically itself to within a couple of cycles - of course, nobody'll notice these things unless i bloody point 'em out [mutter, mutter!]

C64 :: Armalyte menu sorted

The disk menu for Psytronik's release of Armalyte was finished yesterday; i recycled the loader from the Mayhem In Monsterland menu (try saying that three times when you're drunk!) and at Kenz's request added keyboard-based selection since i hadn't even noticed the option in the original!