Cavern Racer
From Retrosoftware
Contents |
Cavern Racer by Jools Henn
Licence
TBC
Introduction
Similar to 1983's Bally Midway classic Spy Hunter, Cavern Racer is a modern MODE 4 software scrolling vertical racing game for the BBC Micro.
Cavern Racer was originally conceived during a discussion at The Videolympics event hosted at the Lass O'Gowrie pub in Manchester on the 4-5th August 2012, after some of the attendees reminisced about a very simple BASIC game from the Usborne book Computer Spacegames, where the object is to escape the forces of the evil Dissectitrons by flying your single-seater Speed Dart along the jagged, bottomless ravine known as Death Valley.
Platforms
BBC Microcomputer
Original by Jools Henn
Downloads
Cavern Racer v0.1 Tech Demo disc version (.ssd)
A quick tech demo for the BBC Micro. Full Mode 4 software scrolling - running at a pretty much rock-solid 50 frames per second. It's interactive, too - you can change the speed with the Z and X keys. You start to get some graphical glitches if you really increase it to breakneck speeds, that's just because the Beeb is having trouble "racing the beam" down the screen when drawing it :)
Usborne Computer Space Games - Death Valley disc version (.ssd)
Before you start, the computer will ask you for the width of the valley - start at 15 and work your way down. 8 is considered quite difficult according to the book. Steer with Q to go left and P to go right.
Screenshots
Cavern Racer v0.1 Tech Demo
Posted: 09:38, 07 Aug 2012
Development Diary
6 Aug 2012
Got the basic demo up and running. Wrote a level converter in Perl, to convert images to the format the game uses, so I can design levels in a paint package.
10 Aug 2012
Added a map to the right hand side of the screen, that shows the whole level, and your position on it. It's really small, so not sure how useful this will be in practice, but it's a neat addition.
12 Aug 2012
Added inertia to the speedup/slowdown controls, to make it feel more like the final game will.
20 Jan 2013
Added a player sprite, 8x8 pixels. Needed to store eight versions of this, each 16 pixels wide, for each pixel offset. I decided to do the calculation of these offsetted versions in 6502 rather than precalculate them, that way we have the option of choosing between different player sprites on the fly later.
I had to work out how to do the plotting / unplotting of the user sprite without the level plotting interfering with it - the usual XOR method could potentially leave a bit of a mess if the user is near the sides. I decided on the pretty simple method of just unplotting the sprite by AND-ing an inverted version of it with screen memory, then plotting it again by OR-ing a positive version of it with screen memory. I also tried the game on an Electron, after fixing the compatibility bug that affected this and Mixed Grill March. It ran reasonably well on the Electron, there was more slow-down, but it's not show-stopping.
22 Jan 2013
Made the main player sprite controllable, so you can now use the normal BBC keys to control it. Added some dampening to the horizontal controls too, so now we have inertia in both dimensions.
26 Jan 2013
The original level I drew in the demo wasn't actually that much fun to play - too many jutting out bits with no warning. I re-drew the level, to make it a lot more fun to zip through at high speeds without crashing into anything.
I also added collision detection, so the game knows when you've bashed into a wall. At the moment, the game just restarts if this happens. This makes the game into something that's actually playable, and it's quite good fun racing along the level at high speeds :)
I had two ideas for improving the fact that the game slows down if it can't render the whole screen in time (especially important for running the game on the Electron). Firstly, we could set an interrupt every frame, so we know if the frame isn't drawn in time, in which case we don't wait for the next VBL when the rendering is finished before rendering the new frame - this should increase the speed from 25FPS to 37.5FPS when slowdown happens. Secondly, we could use this interrupt to decouple the game logic from the rendering - this would mean that the game doesn't actually slow down if it can't draw it all in time, but just looks a little less smooth. But first, I'd have to learn how to use interrupts :)
14 Dec 2013
I've not done much on this game in a while, but I thought I'd finally get round to looking into the interrupts thing I mentioned above. I ripped off the code from the "MovingSpritesMode2" demo on the RS Sample Code page, and made it set blank a "waitForVsync" flag. This seemed to work nicely on the BBC, and it does seem to have made the game slightly smoother. Unfortunately this code doesn't seem to work on the Electron, and it's the Electron that needs this the most (the BBC version was running fast enough already).
15 Dec 2013
Managed to do what I wanted to do with the interrupt by creating a VBL event.
21 Jan 2014
To make the game a bit faster on the Electron, I decided to try out the hacky but fast method mentioned in the Electron article Kees posted on a thread the other week. This worked a treat - the old keyboard reading routine took up 21 scanlines of time (determined by the good old "change background palette before and after" trick). This new method took about 4.25 scanlines - about a fifth of the time! That's definitely a worthwhile saving, on the Electron we need all the speed we can get. But this method only works on the Electron.
I wanted to keep one source file, that contains both BBC and Electron versions, with some lines having lines of code that say "This is for the BBC version" and "This is for the Electron version" and have it all work itself out automatically. I thought for a while on how to do this - and eventually, I decided on a convention. So, any line for the BBC only I add ";VER_BBC" on the end, and any line for the Electron I comment out and add ";VER_ELK" on the end. Then, I wrote a very simple Perl script that comments out any line containing "VER_BBC", and de-comments any line saying "VER_ELK", saving it to a different file, which I import into my Swift project.
So, to compile a version that works on the Electron, I simply run the Perl script to convert the BBC script, and built the project in Swift as normal. At the moment, I have to manually load the game from the disc image on the Electron emulator, otherwise crtl-break would try and load the BBC version, but that's something I can come back to later.
To make the Electron version even faster, I took the "write the same line twice" method the BBC version uses, but expanded it further to "write the same line four times". It'll mean the Electron version will look blockier, and has a strange ripple effect when moving slowly (which is strangely nice), but it'll run faster.
22 Jan 2014
The Electron version is still running a bit too slow, though. Not surprising really, when you consider the BBC version is using between 75% and 100% of the CPU time to render the screen. After a long time messing about this evening, I finally worked out a usable solution to this.
It involves noticing when the VBR happens mid-plot, and if that happens then we save the current plotting details, plot the spaceship and map, and do all the other game logic that has to be done every frame. Then, we come back and continue the plotting of the main screen from where we left off. Also, if we're continuing from where we left off from last time, then when that frame finishes, we need to immediately start plotting the current frame that we postponed.
I spent quite a while messing about with this, but the end result is that the game logic on the Electron version now runs at the same speed as the BBC version, so effectively the game plays pretty much the same, it's just not quite so silky smooth (the game screen updates about every 20Hz-30Hz, whereas the BBC version is pretty rock solid at 50Hz). Not bad for an Electron!
That's enough Electron tweaks for now... next, it's time to start fleshing out the game a bit...