Computer Development in 30 years

Uridium C64 Graphics

Way back in the early days of Uridium; I was keen to get a full 50 frames per second high-speed scrolling game. On the one hand, the C64 graphics chip was pre-programmed to decode a 1,000 character map via the 2K of character graphics onto the display screen every 50th of a second, for free, well almost. On the other hand, aside from setting the scroll offset in hardware by 0 to 7 pixels for smooth scrolling, just leaving the data as-is, you can only make it move by 8 pixels. In order to slide sideways by a whole character, you have to rebuild all 1,000 characters on the screen. Therefore you'd have the whole level unpacked in a larger map and copy the 1,000 characters that you needed. Every processor cycle counted big-time, so if you want to copy 40 characters per line you might repeat the same copy instructions 40 times rather than implement a loop with a count. It's the same count every time; why not just put that number of instructions in? You could unravel the Y loop as well, but then the code would take about 1.5K of space, which was about a 40th of your available RAM space. We didn't do that.

 

Since the Uridium manta ship can move at 1 character (8 pixels) every 50th of a second, I rebuilt the screen every frame. Might as well take the hit because you can't guarantee that you won't have to do that anyway. That also means that any alterations made to the background map get actioned on screen immediately. This copy process might typically take almost half the frame to do (it was a split screen, so only 21 x 40 being scrolled). Whilst we could have implemented double-buffering, we didn't to save space, and relied on copying the new screen data over at a time when the display raster would not catch up with the copy, avoiding screen tearing. Actually, I was updating some of the colour map too, and you only get one of those, so it can't be double-buffered. I had to note where I had updated last time, clear those, then spot the new positions with the next animating colour for the Uridimine ports.

 

The background stars, as someone figured out, are an animated character counter-scrolling so that they appear in the same position on screen regardless of the scroll position. The star character only replaces the blank space character on screen, not a solid one. It's quite usual to have the easily identifiable first character as the blank space. I also had to ensure that there were no stars in the area where the Manta shadow could be cast, because the colours were all back-to-front and the shadow would have cast on the stars - yeuck!

 

The C64 allows sprites to selectively go behind 2 colours and in from of the other 2. The shadow colour was the same as the darker background colour, and was told to go behind the blackness of space, and behind the background shadow colour, which are the same anyway. This allows the shadow to cast onto the mid background colour and the highlight colour. Previously, shadows had typically been simulated by alternating black and not displaying, which effectively only runs at 25 frames per second and strobes rather. Flying Shark does this. Conveniently also, the Uridimine port was cycling foreground colours for a glow effect, and the shadow went behind that too, as casting a shadow onto a light emitter would look wrong.

 

The last character trick I used was to reserve some background characters for the Manta bullets. By working out what the background character was behind a bullet, I copied that graphic to one of my reserved characters, then overlaid a bullet graphic in, and plotted that reserved character onto the screen. That also meant that I could quickly get the enemy ships to detect a bullet character under them because all the bullet characters were in a preset range, and they'd blow up. Bullets were always character-aligned and moved at 2 characters a move. Enemy ships had to check three adjacent characters under them to make sure they didn't miss. Bullets fired on button down and button up, so there were plenty around. That was an important feature to get lots of movement on screen. Hated the Space Invaders and Galaxian limitation that only allowed one player bullet at a time.

 

I didn't have a sprite multi-plexor at the time, and probably wouldn't have been able to afford the processor time anyway. I decided that the enemy ships would be flying higher and not cast a shadow (convenient!). They don't therefore ever collide with the player; I don't especially approve of kamikaze enemies. The Alleykat racers would stupidly collide with the player, but at least you had energy and could potentially sustain such collisions.

 

So... that's what you can do with a graphics chip helping out with characters and sprites.

 

Next time: the Amiga equivalent.