I just say that bullets would go out in alternate colours so the player could tell when collisions are going to be checked. This may reduce computing time and still feel precise enough for the player.

Can you expand on this because it all sounds a bit illogical to be honest? When you say "alternate colours" do you mean alternating the game frames the bullets move on (half on even frames, half on odds) or something else because it's not clear what changing the colour of a bullet would have on accurate collision detection? Do you foresee a frame of the game where some bullets are not being checked for collision detection at all?

0 x

"He made eloquent speeches to an audience consisting of a few depressed daffodil roots, and sometimes the cat from next door."

I don't know maybe you can disguise a ray by drawing a line as a gradient from light (bullet end) to dark (tail end) giving it an appearance of motion so that your fake bullets seem to travel a shorter distance than they actually do each time you check for collisions.

Done a bit more bunnycoding.
Looks like it'll be all too easy to drop down to four frames where there's a lot going-on on-screen.

I've added some code to draw wall-like obstructions like rock spikes sticking out from the top and bottom of the screen, a bit like what you see in DELTA on the C64. These are like double-height sprites but quicker to draw, so long as they stay in the top or bottom third of the screen and don't straddle the 2K boundaries. I've also started sketching a couple of alternate backdrops, though it's hard to make a screen look interesting while being sure to re-use enough tiles for it to store efficiently. I have made it so the backdrops can be re-coloured on the fly so they can be re-used for later levels.

I've also integrated the Special-FX tune player from Beepola to add some incidental bits of tune between levels. Not sure whether to go it alone or see if someone more experienced with it would like to tune-up my tuneage. For a main tune I found a useful website http://www.musicnotes.com that has lots of simple arrangements of pop songs and popular tunes - though maybe an original piece of music would be better?

I did find a bug in the player though - there's an ADD A,L and LD L,A to step through part of the tune or part of a percussion effect, to add A to HL. But if the table it's using spans a page break it can't do the sum in 8-bits and it crashes. Had to change it to LD D,0 / LD E,A / ADD HL,DE to do the 16-bit sum properly.

I'm drawing the backgrounds in ZX Paintbrush. They come out as three screens wide and a third high.
I've written myself a compressor so that it can pick out re-used 16x16 blocks and build up a map. So I try to use a lot of copy+paste when designing to keep it efficient. The pain in the arse is making sure that the attributes are all the same even in the character cells that don't have any visible pixels.
I'm trying to keep it to around 4:1 compression, so using around 40-48 blocks over 192 map cells on each level graphic.

I loosely based this view on the reddish interstitial night-time views of 'National City' from series 2 of DC's Supergirl, which I gather is really showing the cluster of towers that make up downtown Los Angeles, with the hills in front and the suburbs spreading out behind.

Always loved the Speccy colour palette, so vibrant, even given it's limitations. The C64 had more colours yes, as did the 464. But in those modes the pixels were widened and blocky to boot. The 464 had a nice palette, could put out some nice pics given the care it rarely got, but the palette of the 64 was awful, really earthy/muddy. I'll go for the attribute clash and the better resolution thanks.

I think I needed my own label if I've made more than one game! 'Ionian' comes from sitting at a desk here while writing the Buzzsaw+ title screen multicolour code:

I've written some tools in Borland Visual C++. The background one loads a .scr, then cuts it up into 16x16 tiles. You'll notice the whole thing uses the same 25% offest stipple, so each tile can be shrunk down to 8x8 pixels and 2x2 attributes. (The scroll routine expands them out again into alternate pixels on alternate lines).
The compressor then compares each tile with any that it's already done and replaces them in the map with the previous tile ID. Then the map and the minimum tile set are saved as defb data statements.

I've also written a simple run-time compressor for the logo that can skip empty characters and re-use attributes to save data space. It's not doing the most efficient algorithmic compression you can get, but it's quicker to decode by using something simple that works in whole bytes rather than a compressed bit-stream.