How Battle Eagle works

My Atari 8-bit scrolling shoot ’em up Battle Eagle was released recently and came eighth in the annual ABBUC software competition, so as promised previously here’s a quick write up of how the more interesting bits work. But before I get too caught up in the “technical” stuff there’s also a little history to cover; the name is a fairly cheap play on Warhawk because Battle Eagle version 1 was attempting to be similar to Proteus Developments’ budget shooter, sticking to some fairly strict self-imposed “rules” that included deliberately limiting things to single colour in-game objects and not employing sneaky sprite engines. The early test code without any proper graphics or wave drivers looked like this…

…and was shelved because it didn’t work particularly well, suffering with some fairly nasty visibility issues. When I started thinking about writing something that used a character-based 4:1 pixel ratio mode back in 2012, that prototype donated a scroll routine before everything else was written from scratch. The name survived despite the major rewrite and a fairly fundamental change to the gameplay (the craft flies through the landscape rather than over it) just because I thought it still worked.

From a technical perspective, the final version is mostly quite simple; the backgrounds are character-based and using a 4:1 ratio pixel mode so each character has two columns of eight pixels which can each arbitrarily be one of sixteen luminances of a shared hue. The scrolling uses a 1K buffer and an LMS command on each character line (LMS commands are part of the display list and can be used to specify the mode and memory address for each character or pixel line) and, once the hardware smooth scroll shifts everything eight pixels down, the LMS addresses are rotated and the bottom line recycled to the top before it gets overwritten with the next row of graphics.

All four of the two pixel wide missiles are set to quad expansion and coloured black to mask off the the sides of the playfield (otherwise the background colour and enemies arriving or leaving horizontally would have rather messily extended out into the borders) and all of the players are set to double expansion and working in pairs to get three colour objects that loosely match those 4:1 ratio pixels of the background. The player craft takes two of the players and is just cleared and redrawn once a frame in a pretty standard way, but things start to get a bit more hairy when we get to the enemies.

There can be up to four enemy objects in motion at any time and they’re all generated from just the two remaining players. Objects each cover twenty three scanlines when drawn, which means four blocks of twenty three bytes, two written to the player definitions and the rest going to a couple of tables used to set player X position and colour for each scanline (so that’ll be around 115 bytes cleared and written per enemy each frame but it’s actually a little more). There’s a worryingly large unrolled loop running during the play area which is reading the two tables and dumping them to the player X positions each line and colour registers every second because there isn’t enough time to write all four registers on the scanlines where the machine is fetching screen data.

So objects are basically requesting the use of the hardware sprite pair for the space on screen they’re using and the problem with this is that, if there’s a conflict, whichever object requests the shared area last gets to use it, with the other occupants being partially or potentially totally invisible. The attack wave script has been arranged to prevent that happening almost completely, but for those rare occasions where it does (usually because an explosion is moving at a different speed to the object it replaced) the engine draws enemies in reverse order every second frame and two overlapping objects will flicker where they meet but remain visible.

That sprite engine means that the processor is tied up for around 192 scanlines and then the game has to clear and redraw the player object and it’s bullets, reset the X position table where the enemy objects were last frame (they don’t have to be cleared from the player data) and draw them into the work spaces at a close to rock solid fifty frames a second even when there are another sixteen bullet objects in play for the boss battles.

There’s a reason why it doesn’t have in-game music…

The end of the war

Battle Eagle is finished and sent off a day before the ABBUC competition deadline! For those who haven’t read the previous posts, Battle Eagle is a vertically scrolling shoot ’em up that uses the Atari 8-bit’s 80×192 pixel sixteen shades of one hue graphics mode and hardware sprites which are horizontally expanded to make them fit in a bit more cleanly. Here’s a short video of the title page (with some of the music composed by Sascha “Der Luchs” Lubenow) and some of the first level:

Here are some “interesting” facts about Battle Eagle just because I’ve remembered how to do bullet points today:

  • It has 50FPS smooth scrolling using a character-based screen mode.
  • There are 60 screens of scrolling background constructed from 3,620 4×4 character tiles.
  • Up to four independently controlled enemies, all generated with just two hardware sprites.
  • There’s 106 frames of animation for the explosion, player ship and enemies in there.

At some point I’ll try to do another post mortem like the one written for Callisto last year but for the moment here are a couple of screenshots and the game itself will be released onto the Cosine website as soon as the nice ABBUC people give the okay.

The battle continues

A bit more work has been done to Battle Eagle so there are three level maps installed and pretty much populated now and a handful of enemy animations have also been added so here’s a picture of one in it’s natural environment:

The four enemies currently handled by the engine are managed on an object-by-object basis so each can be a different base colour and definition. At this point the idea is that there will be about six stages which alternate between two graphical styles and, hopefully, have a bespoke enemy definition as well as access to a general pool for things like the now grey space mines but the final numbers pretty much depend on available RAM.

Part of me wants to keep everything to a single 48K load because it wants to write for a stock, tape-based machine (which for the Atari 8-bit would be a 48K GTIA-equipped 800 since that’s what most 1980s budget games wanted) but there’s another area of my psyche insisting on unrolling loops for speed and the two really don’t get on and if the latter wins the three of us will be aiming for 64K. As it stands the entire project takes a smidgeon over 40K when executing but there’s a generous gap where the music will be going, some work spaces that can be moved or optimised and the sprite and tile data have some “dead air” at the end which will be clawed back soon.