SoftQuake 1.2.0

Quake Quake Engines
1

– Version 1.2.0 is out. You can get it here –

Windows x86:
https://github.com/voidstar-dev/SoftQuake/releases/download/1.2.0/softquake-1.2.0-win32.zip

Linux x86:
https://github.com/voidstar-dev/SoftQuake/releases/download/1.2.0/softquake-1.2.0-linux.tar.gz

Latest Changelog

*** 1.2.0
*** 2023-12-04

  • Add -Wformat to the compiler flags.
  • Annotate printf style functions so that the compiler can catch formatting errors.
    Replace some sprintf calls with q_snprintf.
    Fix format string mismatches.
  • Add -Wno-dangling-else, -Wno-pointer-sign to the compiler flags.
  • Mix_OpenAudio has been replaced with Mix_OpenAudioDevice. This ensures that music files are played with the requested format. Prior to this, the implementation was free to modify the format.
    SDL will convert the requested audio format under the hood to what the OS expects.
  • No longer assume WAVE file support. This is now checked at runtime with Mix_HasMusicDecoder().
  • No longer disable music playback if Mix_Init() returns 0. At the very least, support for a wave decoder is checked.
  • Give a more informative error message if an audio track for an unsupported format is found.
  • Fix buffer underflow in COM_FileBase. When compiling with Clang under Linux, the program would crash upon loading a new level.
    This was caused by an unchecked pointer decrement.
    With this fix, you can now compile the Linux build with Clang without crashing the game. Just call make with CC=clang.
  • Change main Windows Makefile flags to use regular -l for library linking.
  • Add host_sleep cvar. Defaults to 1. This sleeps the game for 1 millisecond after each frame. Set to 0 to disable.
  • Fix invalid GLSL syntax in the vertex and fragment shaders.
    Nvidia’s drivers were accepting the shaders as they were written originally, whereas AMD’s drivers were not.
    varying in and varying out have been changed to just varying.
  • Add glGenTextures call for the OpenGL software backend.
  • Misc formatting and typo fixes.

Hi everyone.

I’d like to introduce a project I’ve been working on since July 2023, which I call SoftQuake.
In essence, this is cross-platform port of the original software rendered version of Quake.
The goal for this project is to bring the original visuals of the software renderer outside of DOS and WinQuake, with minimal to no changes to the engine.

First, a bit about me…
I’m just a lone C developer who enjoys writing code, and also happens to enjoy Quake.
This project was just my way of having some fun and bringing something I really wanted to see to light.
I’ve never any kind of online presence on any Quake forums, so this would be my first foray into this sort of thing.

I started with the original source code release, which can be found here:

(Well, not the original on the web, but you know what I mean!)

Over about 1 week I whipped up a port that runs on Linux and Windows.
Here are some screenshots of the progress so far:

Start

E1M5

Arcane Dimensions Start

Yeah, I didn’t exect that either, this is the unmodified engine code!
Even the breakables and projectiles work.
Note that I’m looking in the corner for a specific reason :slight_smile: The engine culls more distant map geometry otherwise. I haven’t figured out exactly why it does this yet. The rest of the maps (except ad_chapters) don’t work, unfortunately. Also, you need to use the -mem commandline option to give Quake more memory at startup. I used -mem 32 and it was sufficient.

Video options screen

Video resolution is independent to framebuffer resolution.
Currently, framebuffer mode supports multiples of 320x200 (1x, 2x, and 3x), but can be extended to support more modes.

I have a more detailed bit of documentation https://github.com/voidstar-dev/softquake-testbed, as well as additional screenshots, for anyone interested.
However, here are a short list of features:

Game:

  • Base game support
  • Mod/map packs
  • Audio (SFX)
  • Emulated CD Audio (requires a tracklist rip)
  • Keyboard/mouse support
  • Multiple framebuffer resolutions (the screenshots were captured at 320x200)
  • Fullscreen/borderless/windowed modes

OS:

  • Windows support
  • Linux support

Libraries:

  • Uses SDL2 and SDL2_mixer for easy portability

Other mods tested:

  • Shrak
  • Copper

Releasing:
The actual game works, and this post here is my way to gague if anyone would be interested in helping me prepare this codebase for actual release.
It currently compiles on Linux using GCC, and cross compiles to a Windows exectuable with MinGW, but it is far from a user friendly install/compile process.

If anyone is just interesed in the code as-is, I could potentially also post that, but be aware that (at the moment) it’s a very Linux-centric build process.

In case anyone missed it:

PS: I have also ported GLQuake in the same manner (original codebase, no visual changes), but I’ll save that one for another topic.

Special thanks to the QuakeSpasm devs. Your code was/is an invaluable resource for writing this port.

Thanks for reading!
– SoftQuake developer

1 Like
2

This sounds and looks FANTASTIC!
With Ironwail one can force big Q to look almost like the original 1996 version but this looks like something even closer to the software render. Id download and run it day 1.

Wish You all best on the project!!!

3

FYI: https://disenchant.net/tyrquake/ has a software renderer and was last updated in 2022 (can run ad_tears and everything). It’s less faithful than the stated goal of SoftQuake (think Crispy vs Chocolate Doom), but could be another point of reference?

4

Thank you for the encouragement! I just spent the last day polishing up the video options screen, it’s among the last additions I have left, and one of the most important. I really don’t want anyone to end up with a black screen because of a mismatched setting.

Now, when using fullscreen mode, refresh rates are respected. I’ve only tested wth a 60 hz and 75 hz config, but both work. Borderless mode just uses whatever the current display settings are. There’s some work left still, but it’s getting close to complete.

I actually found out about Ironwail only a few days ago, thanks to https://www.youtube.com/watch?v=9MO3GxoNm8o video by dumptruck_ds. The video is an excellent overview of the engine and the capabilities it brings. I have to say, I’m really impressed by how close the 8 bit mode is to the software render. Whoever authored the shader/conversion code for that did a bang-on job :slight_smile:
Here’s a comparison:

SoftQuake 8-bit (640x400 framebuffer)
https://github.com/voidstar-dev/softquake-testbed/blob/master/screenshots/softquake-8bit-test.png?raw=true

Ironwail 8-bit
https://github.com/voidstar-dev/softquake-testbed/blob/master/screenshots/ironwail-8bit-test.png?raw=true

Also, thank you for brining up TyrQuake. I have not heard of it up until now, it looks like a pretty good port. I was able to get it up and running on my machine with no issues, but I did have to change the Makefile to use SDL instead of X11. Your observation is correct in that my goals are to provide a much more minimal port (I also made a nod towards Chocolate Doom in the readme file). Lots of talented people have already extended the engine well beyond the original design, and I’m not sure I can best that, nor is it something I’m particularly interested in recreating at the moment.

After the video settings are finished, I’ll work on re-writing the Makefile system, and also see if I can get a native Windows compilation build script going. At that point the project should be ready for a “beta” release. I’ll append any major update progress back into the initial post.

– SoftQuake developer

5

Um, kindly pointing out that I’ve had this little project with an identical name for quite a while now, with a similar goal (focusing on the software renderer, but it’s Windows only as of now)

https://github.com/Azarien/SoftQuake

admittedly, not much has been going on there for the past few years, but I might come back to it one day…

6

Azarien, I wanted to message you on Github but to my surprise there’s no messaging system there (yeah, I know I’m late to the party :))

It was never my intention to use an existing name, I just came up with it independently when I started writing this port.
Would you be okay with me continuing to use the same name as your project?

I’ve been working on the finishing touches this week, and the project is just about ready for its first release (nothing released yet as of this post).

If the name conflict is an issue for you, I do have a few other names I’ve thought of since, but it would be nice to use the existing one.

I’ll hold off doing the release for the time being.

7

I am always a fan of more software Quake! This looks phenomenal, very glad there’s still people trying to keep the software renderer going on modern machines (even though I personally use Ironwail cranked up to full crunchiness these days for compatibility reasons–also colored lighting, which doesn’t work in most software engines, possibly any? Didn’t Qbism get colored lighting working?)

And hey, if the name conflict is an issue, can always call it Chocolate Quake. I think that sounds delicious.

8

Okay, you can continue using that name for your project.

9

Thank you Azarien, I am very greatful!

mariteaux, thanks for your kind words! I have chosen to stick to SoftQuake, but it’s a good name nontheless :slight_smile:
I didn’t implement colored lighting in this port either, it’s about as barebones as it can be. Colored lighting in software renderers can look very nice (I’m thinking Unreal and Half-Life 1 in software mode).

For those who have been waiting for the release, thank you for your patience. The 1.0.0 release is up now:

https://github.com/voidstar-dev/SoftQuake

10

Version 1.1.0 released.

11

Version 1.2.0 released.

Most notably, the shaders now contain valid GLSL. The driver on my main machine was a bit too lenient at accepting incorrect syntax.

For those that are compling this project from source, it’s now possible to compile this with clang on linux.

I did manage to build this project on Windows with clang without using MSYS2/mingw, but at the moment it’s too fiddly due to slight differences in compiler switches.

More releases to follow soon.