Archive for July, 2010

Retro Gamer 78

Wednesday, July 7th, 2010

Just a quick post, got hold of Retro Gamer issue 78 and the 8-bit reviews were of the rather lovely platformer Adventures in Time for the Plus/4 (and there’s an interview with Kichy and Luca), a conversion of the Vectrex classic Spike to the C64, a Spectrum platformer called Heart Stealer and Diamondz, a neat little puzzle game for the Atari 8-bits.

For the remake and indie bit, there’s Magnetron for the NDS (it’s a Robotron: 2084 clone with bits of Llamatron for good measure), JNKPlat 2010 on the PC and Shoot 1Up for XBLIG, with the Flash game being Hue Shift.

Colour for colour’s sake

Tuesday, July 6th, 2010

One of the things I’ve noticed about trying to draw graphics for 8-bits is that the machines with higher colour counts are harder to produce something decent for than those with a more limited palette. Actually, I noticed this years ago when trying to get my head around the Amiga after several years of cramming everything into three or four colours with the C64, but it’s recently been rather frustratingly reinforced by a couple of doodling sessions between stints of writing reviews.

One particular compulsion seems to be that, when there are lots of luminances of the same colour available, objects get drawn using shades of a single hue despite the “real” world not usually looking like that; bushy-topped, cartoon-like trees with five shades of green but no other detail until the rather sudden transition to multiple browns for the trunk, brick walls where even the grouting is a vibrant red, bright purple bias relief dreadnought spaceships (this one isn’t so bad, aliens may well want a purple ship) and so forth.

The other, far stronger urge when there’s a large palette is to wedge colours into the bloody display just because the hardware can do it! That might not sound like an issue as such, but colour for colour’s sake usually turns into a waste of other resources, with the obvious example being rainbow splits through the background colour register – yes, they’re a cheap and relatively cheerful way to get large swathes of colour into a display, but for most machines they take a fistful of processing time to actually maintain, CPU grind that should probably be running the game.

When the hardware supports truly bonkers amounts of colour use, trying to cram a myriad of hues into graphics can also lead to situations where an object could have been rendered nicely in four colours but has instead got twelve just because it can; for example, some of the presentation graphics for Blok Copy on the C64DTV have loads of “detail” that was layered on to get the colour count up because it felt like short changing the system if I used the 8BPP 320×200 256 colour mode without splashing the hues about a bit – that font in particular probably looks like chroma distortion on some televisions! Even worse were the first tests of the unreleased Atari 2600 version called Shyfter that used thirty five colours for the tiles, seven hues across by five luminances down – the start screen looked fabulous, but it was rather rapidly cropped back to just one shade per column because trying to get that playfield back to it’s initial state was nigh on impossible.

The trick (and it’s one I’ve struggled with quite a bit, which is why there’s probably a slightly frustrated air to this post) seems to be self restraint and trying to get something decent-looking that has a reasonable colour count without going absolutely Tonto in the process can be a right bugger…