At the homebrew meetup a couple of days ago, I was discussing with some of you the new game I was working on - a cavern racing game (I'm using the working title of "Cavern Racer", how original).

I was wondering, was the BBC going to be fast enough to do what I wanted to do? - namely, full software scrolling in Mode 4? The only way to find out was to try it. Well, my first attempt ran at about 1/3 speed, so I had to simplify it a bit. Gone are the walls in the middle of the screen, and I've halved the vertical resolution of the walls.

So, here's a quick tech demo. Full Mode 4 software scrolling - running at a pretty much rock-solid 50FPS

Excuse the "drawn in MS paint" style of the level. I might need some help drawing levels at some point (I've written an image-to-level converter in Perl)

If it looks slightly juddery in an emulator that's probably because it's trying to show a 50Hz Beeb on a 60Hz PC screen - run your emulator at 25% or 10% speed and it's nice and smooth.

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

Enjoy!

Wow, that's mighty impressive, Jools! Especially at full speed!

This has heaps of potential ... !

Hi Jools,

looks very impressive indeed.

This is done by software scrolling?
Are you shifting 10 kB every 1/50 sec?

Kees

Yep, 100% in software poking at screen memory, no hardware tricks at all.

The secret is, of course, to not re-draw the whole lot, but only to redraw the bytes that have actually changed since the last frame. So, for each line, we plot the byte where the left wall is, then compare that byte's offset to what it was last frame. If it's the same, then we're done. If it's not, then fill in the bytes in between the two points with $00 or $FF as appropriate. Repeat for the right hand wall. For speed, it plots them two lines at a time, so there's less logic to perform.

Quite proud of the result, it seems rock solid up to as fast as you'd practically want to go in a game...

Cool!!

Wow, Jools.

That's quite hypnotic ...


That's already looking a lot better than the minimal improvements I remember making to the original Death Valley game.

BTW, for anyone interested in seeing the original type-in that was discussed at The Videolympics which was an inspiration for Jools' new game, find attached a .ssd with the original 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. 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.

It's surprisingly good for such a simple program.

Sam.

Good going

A rather fancy version of a game where you just avoid the walls was Jet Boat on the BBC Micro, I spent a lot of time on that as a kid.

It also reminds me of that very addictive Vectrex homebrew title VeCave

Top work and nice to meet you last weekend!

Before I shelved this a few months ago, I added a little map on the right hand side of the page so that you can see where you're going (not sure how practically useful it will be, as it's too small, but it looks neat), and some inertia on the vertical controls.

I've just got round to picking this up again, and have done a little more work. I've added a little spaceship at the bottom which moves - you can't control it at the moment, but that's the next thing to add.

Just for fun, I tried the game on an Electron emulator to see how well it worked. It didn't - it drew the screen then just locked up. Traced the problem down to the "wait for vertical blank" code:



Anyone got any ideas why this would lock up the Electron, and what I should be using instead?

I commented out the VBL wait, and the game runs. It doesn't run anything like as smoothly as on the BBC, but it looks like it's fast enough to be playable - so an Electron port of this one could be a practical proposition (though it'll be much nicer on the BBC).

Your ship is now controllable - I now need to tweak the acceleration and inertia a bit so the game feels nicer, and add some collision detection.

Then I've got to decide how to make it into an actual game. I've got a few options here - perhaps an arcade racing game style, where you've got to do so many laps against a decreasing timer, that gives you more time every lap? What about crashing into the walls - do I use a lives system, or simply have a time penalty for crashing?

Whatever I do, there's going to be some kind of tournament mode where you can take it in turns to see who gets the fastest time.

Anyone got any ideas on why the VBL wait locks up the electron emulator? Looking in the Electron manual, it should work... *FX19 is the correct command for the Electron too, and it works fine from basic, so it's all a bit mysterious.

Because you're writing to the CRTC at one point (R10). As the CRTC register select at $fe00 is the same address as the Electron ULA interrupt control register this disables the vsync interrupt, causing a hang on *FX 19.

You're the Man, TomW, thanks

After a bit of trial and error I narrowed it down to this function I nicked from somewhere that turns off the annoying flashing cursor.

Is there a more compatible way to do this?

VDU 23,1,0;0;0;0;0;

Thanks, works a treat. I thought there was a way of doing it using VDU codes that I used back in the day, but I couldn't remember what it was or find it in the manual.

This also lets me see how Mixed Grill March (that used the same code) runs on the Electron. And the answer, predictably, is hilariously badly - the first part of the game runs at about half speed (including the music, which also struggles with the single sound channel), and the people are a flickery mess. The chase sequence (which pushes the BBC close to its limits) runs even slower still, perhaps 1/3 or 1/4 speed. Suppose that's why they didn't make many electron games using mode 2...