Doom?

[RobC]

I've managed to get Doom up and running on the Beeb and Pi co-pro. I'm currently using a Master with VideoNuLA as the host but am hoping to get it running on a standard Beeb.

The menus and title screens look good but the game doesn't look the best as, although I optimised the palette for 16 colours, I've only just discovered the colour map that handles the shading. I've found a 16 colour EGA palette and colour map so may try using that as the next step.

It doesn't have sound yet but generating the PC speaker sounds on the Beeb looks fairly simple.

[VectorEyes]

We urgently need pictures.

[mr-macrisc]

We urgently need pictures.

Agreed.... And nice work

[RobC]

We urgently need pictures.

To be honest, it looks so bad at the moment that I deliberately didn't post a picture! I'll put up some screenshots or a video once I get it looking better.

Looking at the way the 16-colour EGA mod works, I'm pretty sure that the colour map is the key. At the moment, too many colours are getting shaded to black rather than keeping their original colours so the picture looks like it has holes.

Although the screen tearing isn't dreadful, I also need to put bank switching in. I deliberately kept it simple so I could see what was being written to the screen but it'll be easy enough to update ACCCON on vsync.

I'd also like to render the status bar in mode 1 (or redesign it to 160x32) as some of the information is unreadable at the moment.

[soviet]

Having doom on the BBC will be the coolest port ever for an 8 bit .

[mr-macrisc]

Think he has roof and floor rendering nicely so just walls to sort before some photos

[RobC]

Sorry for the lack of an update on this - most of my free time this week has been spent making VideoNuLA boards.

I have managed some progress but I'm still stuck on the walls. I've realised (or at least strongly suspect) that it's not the palette or colour map but that it's just not rendering the wall textures correctly for some reason. Instead of the correct textures, I'm getting horizontal stripes!

Other than that (and a weird bug where backwards takes you forwards several steps), it all seems to be working. The menus all work, the wipe effect works, I can move around the map, collect objects, open doors and shoot the baddies. The frame rate isn't too bad and it seems quite playable. I've even managed to modify the status bar so that it's more readable in mode 2.

If anyone understands Doom well enough to lend a hand then I'd certainly appreciate some advice. (E.g. some of the patches in PNAMES aren't present in the wad but I don't know whether that's significant. I suspect not as the wad runs correctly on DOS Doom but I just don't know enough to be sure!)

[RobC]

To cap a great day, I've finally managed to sort out the walls

A boolean in one of the texture structures was being treated as a single byte value when the wad held it as 4 bytes so all the texture widths were being read in as zero!

It's all rendering correctly now so I'll try to make a video tomorrow. I'll also look at sorting out the backwards bug and adding sound.

I am wondering whether double buffering on the model B is going to be possible though. My plan had been to backup and restore the filesystem workspace using the co-pro's memory on file operations but didn't realise that file operations happen during gameplay. It should be easy with ADFSE00 but I don't know whether that's an option for most people?

[mr-macrisc]

Brill..

Look forward to vid

[trixster]

[marcusjambler]

[tricky]

Great news Rob, does colour or greyscale look better on the beeb?

[RobC]

Great news Rob, does colour or greyscale look better on the beeb?

Thanks. I've currently only tried the 16-colour EGA palette as seen here. (This is a video of PC Doom running the same palette so the frame rate is higher and the resolution is 320x200.)

Trying other palettes shouldn't be too difficult as everything is taken from the PLAYPAL lump in the wad. If I can find a fast enough algorithm, I'd like to see if it's possible to dynamically generate the palette on a frame by frame basis.

I'd like to see what the status bar looks like in mode 1 - I've redesigned it for mode 2 but it might be better at the original resolution.

[mr-macrisc]

Anything close to that would be crazy good.

Dynamic palette would be very cool assume that could make it look/act like it had even more colours than 16? Though 16 does look fab. Be nice if we can snag double buffer somehow but guess cnst have everything. Although guess it's not out of realms of possibility most people with nula may have shadow ram and a lot could have e00 if it makes a noticeable diff having it double buffered.

[RobC]

Anything close to that would be crazy good.

Dynamic palette would be very cool assume that could make it look/act like it had even more colours than 16? Though 16 does look fab. Be nice if we can snag double buffer somehow but guess cnst have everything.

Cheers. The dynamic palette should create the best palette for the current view although I can't decide whether changing the palette every frame could be off-putting.

I've currently got it double buffering on the Master. Double buffering on the Beeb may still be possible if I can figure out how to get Doom to load all of the lumps at the start.

[tricky]

What resolution are you going for for each of the game and status areas?
How much memory do you need for your code etc?

[RobC]

What resolution are you going for for each of the game and status areas?

It's currently all done in mode 2 so 160x200 - 160x168 for the main play area and 160x32 for the status bar.

The original game is 320x200 and some of the font characters in the status bar are only 4 pixels across (so just 2 pixels at 160!).

I'm currently double buffering the whole thing on the M128 but my plan was to double buffer the play area (26,880 bytes) and single buffer the status bar on the B/B+. Any filing system workspace would be "backed-up" to the co-pro and restored as required but I've realised that it accesses the drive in play to reload lumps from the wad. The lump loading causes an occasional pause using my DC so additionally restoring and then backing up the filing system workspace would add a much bigger delay.

So, I'm hoping I can change things to get it all the lumps resident in memory all the time and then go back to my original plan.

How much memory do you need for your code etc?

Not much - the majority of the host code is in ROM. Just need some space for a few buffers in main RAM and I could mandate that it's loaded into 16KB of sideways RAM if that becomes the only option.

[tricky]

So with "vrirtical rupture", you could have PAGE at &1100 if the screen was 154 wide and without only 142 unless you shrink it vertically too.
What is the next size down and what difference would it make to the frame rate?

For anyone wanting "simple" double buffering on a model B/B+, this assumes a 16K mode with the status bar at &4000, the first screen ending with the status bar and the second ending at &7FFF and wrapping around to the status bar. This puts your code after the status bar and in sideways RAM.

[RobC]

So with "vrirtical rupture", you could have PAGE at &1100 if the screen was 154 wide and without only 142 unless you shrink it vertically too.

So this really does have to be hard drive only due to the size of the wads. I think PAGE goes to &1D00 with ADFS and no DFS. Unlike with DFS, I don't know how far you can move PAGE down and still have file handling under ADFS. Is the ADFS memory map anywhere? Alternatively, it should be easily possible with ADFSE00 loaded into sideways RAM.

What is the next size down and what difference would it make to the frame rate?

I think the view size goes down in 16 x 10 increments which is 80 bytes. I'm using a load of unrolled LDA abs, STA abs,X for the transfer so a tad over 9 cycles per byte = saving 720 cycles per frame.

For anyone wanting "simple" double buffering on a model B/B+, this assumes a 16K mode with the status bar at &4000, the first screen ending with the status bar and the second ending at &7FFF and wrapping around to the status bar. This puts your code after the status bar and in sideways RAM.

I've implemented this sort of arrangement for another game I've been working on. However, I was able to get interrupts working pretty well on the CPC emulator so I think multiple ruptures are definitely possible.

[tricky]

I was thinking &1100 for the model B/B+ versions as I was assuming DFS.

[RobC]

I've uploaded a quick video here.

You may want to skip the first few minutes as it takes ages to load - like going back to the old days!

[Lardo Boffin]

That is beyond impressive.

[marcusjambler]

Very very very cool Rob

[trixster]

Bonkers!

[marcusjambler]

uploaded a quick video

Which model Pi are you using Rob?

Marcus

[mr-macrisc]

Wow

[mr-macrisc]

One down side... I can see a lot of people wanting videonula but then I suppose the more that have the more likely programs taking advantage of them will appear.

[mr-macrisc]

Let's make everyone laugh...

Here, RobC? What could we do with a master, nula and Dual PI co-processor?

[BigEd]

Extraordinary, and very impressive indeed. VideoNuLA looks likely to become a must-have!

[RobC]

Thanks for all the positive comments. I really can't stress enough that porting stuff like this to the Pi co-pro isn't that difficult - anything that uses SDL or renders to a frame buffer in not too many colours or too high a resolution could be doable. Apart from tracking down the annoying wall texture bug, I haven't spent that much time on it.

If anyone fancies porting other things, I'm happy to go through how I do it and share routines etc.

I was thinking &1100 for the model B/B+ versions as I was assuming DFS.

Yeah - I realised that. Thinking about it, I don't know how much of the wad could be trimmed out. Certainly some of the patches and all of the PCM sfx aren't used so they could be removed. Might be able to get it on a few DFS floppies then. If I can get the whole wad resident in memory then double buffering on the Beeb should be doable.

Which model Pi are you using Rob?

Pi Zero with an internal adapter inside my M128. The loading is being done off the ADFS HD on my DC. I might put the GoSDC in there as it'll be quicker.

One down side... I can see a lot of people wanting videonula but then I suppose the more that have the more likely programs taking advantage of them will appear.

I don't mind making them as long as people realise that I solder them all by hand and so don't mind waiting! It would be great to see more things using VideoNuLA. Also, I'm going to create a Doom palette for the standard Beeb so those without NuLAs can play it - not sure how good it'll look though.

Here, RobC? What could we do with a master, nula and Dual PI co-processor?

I'd love to try out Tom's idea. I've not done any profiling yet but I suspect the main bottleneck here is getting the graphics over the TUBE. So, I don't think another Pi would help much. I'm sure there are other applications that it would work well for though.