Quake II with 8-bit colored lighting ref_soft.dll

[func_qbism]

This is a replacement ref_soft.dll adding colored lighting and widescreen waterwarp support to the Quake 2 software renderer. Alphatest and transparency are improved as a bonus. darklights work. Not to mention the ddraw palette problem fixed- this one only uses DIB even for fullscreen! Knightmare’s ‘unofficial Q2 patch’ 3.24 is supported, although haven’t tried it on any others.

Oh, yeah, and there’s a cvar called ‘sw_transmooth’ that dithers transparent surfaces.

UPDATE- current release and code here: https://github.com/qbism/Quake2-colored-refsoft

Notes about the code- It can be copied into the 3.24 source folder. (Make a backup for this purpose.) But I don’t have VC 6, so I built it with VS 2013 (project included in the ref_soft folder).
This started with the colored light code leilei added to stock Q2. Shaded light was completed among other things with head-scratching and borrowed pieces of engoo. Waterwarp improvement and dithering are from AROS Quake2.

Q: Can The Reckoning run?
A: Try creating a shortcut instead of the .bat file. I do C:\quake2\quake2_324.exe +set game xatrix (I renamed knightmare’s 3.24 to this). Also let the xatrix logo intro vid play through, but can skip the cutscene vid.

Q: How can bilinear (smooth) filtering be disabled for water?
A: sw_transmooth 0


Xatrix Reckoning


Maric’s ‘The Blue Devoid’




That orange. r_lightsaturation = 2

[Maraakate]

Hey Qbism. I just recently ported your coloured dlight renderer to q2dos as a separate rendering path to choose from. I'm hoping sometime soon I can take some of the ASM for the easier C path stuff (like the if/else for light vs colouredlight pointers) so it can get a speed boost.

Here's a link: http://www.vogons.org/viewtopic.php?f=2 ... 90#p439681

And here is two comparision shots:

[Maraakate]

Also, your code can build just fine in vs6 and in gcc/djgpp the only thing that doesn't work is the pragma hint. This stuff is unknown in those compilers. Not sure how much of a performance impact that is.

[func_qbism]

Welcome, Maraakate. Thanks for the pics. Is the uncolored shot using assembly?

I expect the pragmas have little effect with modern compilers- disabling warnings and optimization hints. I did add #pragma loop(hint_parallel(8)) but didn't follow through with it.

After skimming the vogons thread, I can't recall which model lighting method is used, but I actually like the results, considering palette limitations. The quake2 color palette has a strong bias that will make some light colors look great and others not. In any case I tried to do the minimum possible changes as a fork of Knightmare's 3.24 with Leilei's lighting and a few modern things from ArosQ2.

[Maraakate]

Yes, uncoloured is using assembly. We are using DXEs (the DOS equivalent of DLLs in DJGPP) so video renderer's can be switched on the fly to do timedemos and compares. I went ahead and added it as a menu option in the video menu as well as "Software Qbism".

I've also updated the code slightly to use ASM for stuff that needs no changing. It only resulted in about a 2-3 fps increase though.

One thing that would make it much better is if the gun colour could be tweaked a little. Firing it typically has nastyish green edges aroudn the yellow light which I assume is from the 8-bit conversion process.

I also noticed firing the gun is what brings the framerate down. Is it possible to just have the gun dlights come from a mono light instead? If so, a CVAR for such things would be a good compromise.

I also reduced the lightsaturation to 0.75 by default. At 1 and higher it tends look kind of catroon-ey and overblown IMO. But, it is a CVAR so it can be adjusted to taste.

[Maraakate]

Also, see this commit: https://bitbucket.org/neozeed/q2dos/com ... f9ad4221f3 for speed improvement on the renderer. It's not drastic, but I got about 4-6fps on average gain from running timedemos compared to the previous code.

I also may be able to port the extra lrstepx lgstepx and lbstepx to the ASM function above. It's basically the same code, except a few values are changed. Not sure how drastic of a speed increase it will be, but the closer we can get back to the whole ASM code the better overall.

[Maraakate]

Okay, fixed R_PolysetCalcGradient win32 ASM. This resulted in an extra 10 fps boost in timedemos! https://bitbucket.org/neozeed/q2dos/com ... a4d63295fa

[func_qbism]

That's an amazing performance increase! I just visited your Bitbucket repository to read the changes to r_polyse.c. I'm rusty on the crazy ID386 vs id386ALIAS defines. Looking forward to a win32 release.

[Maraakate]

I have been developing on Windows first then adjusting the ASM as necessary in GCC.

the id386ALIAS is technically a remnant they commented out. I used it to take advantage of a special case hack.

Setting r_coloredlighting > 1 will set a different mode that will use ASM for the Opaque and ClipEdge functions. This results in a fairly dramatic speed increase (previously I was getting about 110FPS in timedemos, using this hack I was able to get about 140). It comes at a cost of the models (including view model) will be renderer with the standard vid.colormap so they will still respond to dyanamic lights casting on them, but it will be the standard white lights. It actually looks quite nice and the speed improvement was worth it for me to keep it in.

I also removed the sw_transmooth since it wasn't using the ASM and it's very hard to tell the difference between the two unless you zoomed in the water. That originally brought the speed up from about 96FPS to 110FPS.

[Maraakate]

I'm also going to try talking to the folks over the NASM and MASM forums for guidance in porting over the remaining small remnants that would allow it all to be fully ASM again.

If this becomes possible then maybe they would able to help with creating an ASM function for generating the RGB table at init. It's not slow that much in Windows, but in DOS there's a noticeable 5-10 second delay on startup.