BQUAKE - PiTubeDirect Native ARM

[dudleysoft71]

As if working on a new DOOM port over the last few weeks, I decided that I needed something a bit more challenging, so today I present
BQUAKE, a PiNativeARM port of id's follow-up to DOOM, QUAKE.

This is actually an ARM7TDMI build, so in theory it runs in BeebEm, in theory, in practice it runs at about 1fps and the game is too dark to work with the default dithered beeb palette.

However quake supports 5 different palette modes.

1. -NULA - Dynamic 16 colour NULA palette
2. -GREY - 16 grey scale colours
3. -ST/-9BIT - 512 colour palette (Atari ST palette)
4. -EGA/-6BIT - 64 colour EGA palette
5. Normal Beeb Mode 2 8 colours dithered

I implemented these modes, however unlike DOOM, QUAKE's palette is much cleaner and works well with 16 colours.

Screenshots:

Here's an ADL file with the executable on:

BQUAKE.zip

(216.76 KiB) Downloaded 67 times

Copy into a directory, create a directory called id1 in the same place.
Then copy PAK0/PAK into id1 for the shareware version, add PAK1/PAK from the full game if you have it.

Run *BQUAKE [-NULA|-GREY|-ST|-EGA]

[soviet]

This is cool , can't wait to test it.
Have to figure out how to get the wad file into the mmc micro sd card.
Maybe theres a windows program ? for that.

[dudleysoft71]

This is cool , can't wait to test it.
Have to figure out how to get the wad file into the mmc micro sd card.
Maybe theres a windows program ? for that.

It only works with ADFS Harddrives for obvious reasons (PAK0/PAK is 18MBytes on it's own) so you need some form of ADFS hard drive solution.

I use Beeb Image (viewtopic.php?f=12&t=14844) to edit my ADFS HDD image directly, it's also possible to transfer files from a folder using BeebSCSI (and Pi1MHz emulation of BeebSCSI) and Disk Image Manager (viewtopic.php?f=12&t=21252) also handles ADFS hard drives

[dudleysoft71]

I've attached a HDD image with the shareware PAK file, this can be used directly in BeebEm, or placed on an SD card and loaded in BeebSCSI.

BQUAKE_HDD.zip

(8.36 MiB) Downloaded 77 times

Since QUAKE is an open source game I've created a git repository of the source used to create the game, to build you need to install the ARM-NONE-EABI toolchain. If you want to modify the assembly source for beebScreen (you shouldn't need to) then you need xxd in your path since it uses this to convert the BeebAsm binary files into C source files, but to build the source this isn't required.

The reposity is here: https://github.com/dudleysoft/beebQuake

[marcusjambler]

stunning work

[tricky]

How about replacing the status area gfx on the ARM side?
You could have a palette swap on the beeb side.
It looks great as it is.

[dudleysoft71]

How about replacing the status area gfx on the ARM side?
You could have a palette swap on the beeb side.
It looks great as it is.

I'd have to look into it, I'm not sure which parts are rendered by the main game code and which bits are in the gc script parts, the script parts will be harder to replace since it would require building a new script file (all the scripts are compiled into one binary file) and then it wouldn't work with mods, I wanted to allow the game to run using the original data unmodified.

[marcusjambler]

I loaded actual Quake onto my Win98 laptop and siphoned the PAK files from there...
My sons jaw nearly dropped off when he saw it running.... on a beeb

[dudleysoft71]

I forgot to mention in the original post that the game supports mouse input, it should work with any mouse that supports ADVAL 7, 8 and 9 to read it's position, such as the mouse ROM on mdfs.net, otherwise you look around with the cursor keys and move with WASD.

[marcusjambler]

WASD not working... 'A' is operational but it makes you look up

Master OS3.2 with BeebSCSI Pi3 copro VideoNula and Gotek

[dudleysoft71]

Okay, I think I might need to provide the config/cfg file too.

[KenLowe]

I've just downloaded the SCSI HDD image and tried running this on my beeb. Unfortunately I'm getting some graphical issues. My machine has PiTubeDirect, Pi1MHz (for BeebSCSI), VideoNULA and RGBtoHDMI.

I've run *FX151,230,15 to get to the native ARM co-pro, and then I get the following:

Is there a problem with it not being able to find the file gfx/pop.lmp?

I've also tried *BQUAKE without any options and that doesn't work either. Am I doing something wrong?

[dudleysoft71]

Hi Ken,
I think the message is just it's check for the registered version. I'm not sure why the palette isn't working in nula. It takes a while to load since it loads straight into the first demo, it appears it's running most of the code since you've got the loading icon in the top right of the screen if you leave it does it get into the demo?

I can't test this build at the moment, I need to transfer the HDD image to my Beeb and run it there to check. If you have the original quake pak files then they can be transferred over and it should work.

Is your NULA working correctly? It should be setting the palette by writing to &FE23 on the host (the code to do the palette writing is injected into the host from the game as part of the initialisation routine along with the screen transfer code), so unless something is masking this I don't understand why it isn't working, what you are seeing is what you see in beebem if you select -nula on the command line.

[dudleysoft71]

I just tested the HDD image on my Beeb and it loaded up fine, NULA palette setup worked, and it's loaded into the demo.

Just reading your description, you mentioned RGBtoHDMI, I didn't think that worked with the NULA because it couldn't pick up the 12bit RGB values from the NULA, try running the game again without -NULA and see if the standard beeb palette gets you into the demo, it takes about a minute to load on my machine, I presume it'll be a similar time on yours since you're using Pi1MHz for the HDD.

[dudleysoft71]

Okay, I think I might need to provide the config/cfg file too.

Here's the config from my HDD version, rename to config/cfg on the ADFS HDD and place in the id1 folder, this should override the default and provide the correct key bindings:
WASD to move, Cursors to look, RETURN to fire, SHIFT to sprint and SPACE to jump.

config.cfg.txt

(1.44 KiB) Downloaded 40 times

[hoglet]

I was able to successfully run this BQUAKE build on my new "monster" BeebFPGA implementation (which includes PiTubeDirect and NuLA to HDMI, running on a PYNQ-Z2 Zynq FPGA board):

Initially I thought it had hung on that screen, but I waited a few more minutes and it sprank into life.

At least in my case, the colours were correct.

Dave

PS: The standard version of RGBtoHDMI is NOT likley to give good results with NuLA.

[tricky]

Nula + RGB2hdmi (original) will basically convert the palette back to the nearest colour in the original Beeb palette.

[KenLowe]

I just tested the HDD image on my Beeb and it loaded up fine, NULA palette setup worked, and it's loaded into the demo.

Just reading your description, you mentioned RGBtoHDMI, I didn't think that worked with the NULA because it couldn't pick up the 12bit RGB values from the NULA, try running the game again without -NULA and see if the standard beeb palette gets you into the demo, it takes about a minute to load on my machine, I presume it'll be a similar time on yours since you're using Pi1MHz for the HDD.

Sorry for the delay in getting back to you on this. Turns out that the machine I was testing on doesn't have NULA

I tried running it again without the -NULA option, but it doesn't seem to be working correctly there either:

Or is that how it's meant to look without NULA in the machine? It does seem to run otherwise, and the demo does run if I leave it for a couple of minutes.

[dudleysoft71]

Yes it is supposed to look like that, unfortunately Quake is rather dark by default, you can open the options menu and increase the brightness, but then it tends to become too bright, it definitely works better with NULA, I think it might be possible to create a more dynamic brightness, perhaps something to look at soon™. Currently it supports non-nula in a similar manner to how it supports BeebEm, it works, but isn't really playable.

[dudleysoft71]

Okay, I've done a first pass of the dynamic brightness code, this definitely helps, basically it finds the average brightness of the current screen, and then modifies the palette to increase the brightness more the lower the average is.
Here's the new version of the loading screen/console, compare this to the original brightness shown above.

I've attached the ADL file if you just want the executable, replace your original BQUAKE with this version, as well as the HDD image with the shareware PAK file.

[trixster]

Just tried this on my NULA-equipped datacentre BBC B - runs great! what an amazing effort.

If i move the same cf card into the Master (which doesnt have a NULA) then the game loads, the quake console scrolls some text, the demo starts to load but after a few seconds cf card activity stops and the game seems to hang). It's not the issue i was having with Elite-TNK (incorrect handling of the cf card) as this cf card works fine on the model B.

Anyone else tried it on a Master in normal mode 2? with a datacentre?

[dudleysoft71]

Interesting, i test my builds in BeebEm running as a master, since you're seeing the console and output that means its sent several frames across the tube, and its already loaded several files from the HDD, so I have no idea what could have failed.

Have you tried running it on the beeb without the -nula flag? It shouldn't make a difference, but worth testing, you can also run on the master with the nula flag, it will just look weird, but it should still run.

The only other thing I can think of is there's something different about the Pi coprocessor in the master, what model pi is in each?

[trixster]

I haven’t tried running on the beeb without the -nula tag, I’ll give that a go this evening. I’ll also try on the master with the nula flag!

Both machines have identical pi0 coprocessors with the same fw on the sd cards.

[dudleysoft71]

Thanks, just trying to eliminate any possible variables. It definitely worked in beebem's master emulation (but very slowly) but i haven't been able to test on a real master.

[tricky]

Have you thought of adding PI-RGB2HDMI NuLA support, which I believe means running in mode 0 but sending the same data as before except line 0 which has a magic number and the palette settings - IIRC?

[dudleysoft71]

I don't have a rgb2hdmi to test with, it would definitely be an option to explore.

Exactly where in the output does it have to be? beebScreen will centre the display so it wouldn't be on the actual first row of the screen, especially since I don't use the full screen.

[marcusjambler]

Struggling with loading after a save.
It seems like the save goes ahead ( bit hard to read )
But when I load it back in the game sits on the console screen with another message thats hard to read.

[dudleysoft71]

Okay, I guess I haven't really tested saving and loading, I know it works on Doom, I will take a look when I get a chance, it's probably something simple.

[dudleysoft71]

I've added support for RGB2HDMI inband NULA palette emulation to BQUAKE,

To use simply install the appropriate version and type:

Code: Select all

*BQUAKE -HDMI

This will use the dynamic 16 colour nula palette.

[AndyG]

Hello, I noticed that on the GitHub repository says there is a version that works with the pitubedirect…like doom. You execute the code with bquake -pi.
“ ==============

New to beebQuake is the ability to use the Pi's framebuffer and HDMI output to generate the display,
in this case the game is now 256 colours at 320x200, you need to be using PiTubeDirect hognose build
and connect a HDMI cable to your Pi. Use -PI to enable the Pi's framebuffer.”


Does anyone have the compiled code ? I am not sure I have my Mac setup to compile this code.

Thanks
Andy