Cavern Racer
From Retrosoftware
(→Cavern Racer by Jools Henn) |
(→Development Diary) |
||
| Line 61: | Line 61: | ||
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 :) | 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). | ||
Revision as of 23:17, 14 December 2013
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).