Truecolor software rendering

Moderator: GZDoom Developers

dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Truecolor software rendering

Post by dpJudas »

Hi Doomers!

I've patched ZDoom's software renderer to use true color (32bpp) for output. The github fork for it can be found at https://github.com/dpjudas/zdoom.

The patch does the following:

[*] Changes the GetBuffer() format from BYTE. to uint32_t. This changes the render target format from palette indices to BGRA8.
[*] Introduces two new rendering variables (dc_light + ds_light) that allows dc_colormap to point at the original palette instead of light remapping with GETPALOOKUP. This effectively allows light levels to be rendered with fixed_t precision.
[*] Updates all the software renderers (R_DrawSpanP_C, vlinec4, etc.) to output RGBA8 instead of a palette index. This means the transparency functions do true alpha blending, and the opaque functions use dc_light/ds_light for true color shading.

I'd like to add the following things before doing a pull request:

[*] Currently only works with the Direct3D 9 target. This is because the GetBuffer format change affects the platform specific frame buffer code.
[*] Replace all the assembly render functions with SSE2 compiler intrinsics. My current patch only tests this for two of the most critical functions.
[*] Maybe evict any palette completely from the renderer by changing the format of GetColumn from BYTE to uint32_t as well. This would enable true color textures, but I'm a bit cautious about this because I'm not sure if Doom is doing any kinds of 'trickery' with dc_colormap beyond GETPALOOKUP.

Since there's a lot of work involved in completely finishing the patch I'm wondering what ZDoom's stance is on all of this. In particular:

[*] Replacing the assembly render functions with compiler SSE intrinsics. My assembly skills aren't remotely good enough to beat a compiler, but I do know to write SSE 2 intrinsics that should beat the performance of any assembly I'd personally be able to write. As a bonus, such a removal should make it significantly easier to refactor the render global variables and functions into classes.
[*] There is a slight performance cost of using 32 bpp for output. In particular for the Direct3D 9 target where the final palette lookup is done by a GPU shader. I'm not sure there will be any real performance loss in the end if GetColumn is also modified to uint32_t, because then there's no palette lookups done at all by the software renderer.
[*] My primary reason for doing all this was to get rid of the banding effects caused by GETPALOOKUP and its ugly palette colors at darker levels. This makes the game look a lot prettier in my opinion (bit more like GZDoom, but diminishing light intact) - yet, if someone has a desire to have the game look exactly like DOS doom they might not like the change.

So what do you think? What would it take to get such changes accepted - if at all? :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Truecolor software rendering

Post by Graf Zahl »

dpJudas wrote:So what do you think? What would it take to get such changes accepted - if at all? :)
Lots and lots of work - work nobody here has time for.
User avatar
Sandro
Posts: 176
Joined: Sat Oct 05, 2013 8:03 am
Location: Erathia

Re: Truecolor software rendering

Post by Sandro »

Graf Zahl wrote:Lots and lots of work - work nobody here has time for.
No offense Graf, but please, could you show more empathy in your responses?

This guy just registered, put some efforts to help improving the engine.. I think the least one - especially a developer - can do is to welcome the attempt, and not being rude... Personnally, I would feel hurt to submit such an attempt and being received by this manner.. :|

I'm certainly too sensible, but I didn't find any politeness in this response and it bothers me a little bit...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49183
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Truecolor software rendering

Post by Graf Zahl »

Oops. Sorry, I didn't notice that there was a link. This is still up to Randi as the software renderer is not my business. But still, as I see it there's a major problem in here that may well be enough to render the thing unusable:

The engine has to be able to switch between paletted and true color mode. In my eyes this is essential. This cannot be done with a #define.
User avatar
Hellser
Global Moderator
Posts: 2730
Joined: Sun Jun 25, 2006 4:43 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11/Manjaro
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Citadel Station

Re: Truecolor software rendering

Post by Hellser »

Oh, please please add this in.. :D
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by dpJudas »

About the define in my branch, that could be split to different functions with a little more work. It essentially just requires that the GetBuffer abstraction can return either one. I suppose that would also fix the issue with regard to keeping the old assembly render functions for the version using a palette render target.

Just to be clear: I'm not suggesting my current branch is pull request ready right now. It is more what it would take on my behalf to make it so. :)
User avatar
Hellser
Global Moderator
Posts: 2730
Joined: Sun Jun 25, 2006 4:43 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11/Manjaro
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Citadel Station

Re: Truecolor software rendering

Post by Hellser »

Things like this does take time. Look at the portal thread, took them a while for it be merged. :)
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm

Re: Truecolor software rendering

Post by randi »

dpJudas wrote:Replacing the assembly render functions with compiler SSE intrinsics
I don't know if this was in relation to the assembly standard with ZDoom or if you wrote some of your own, but as far as the paletted routines are concerned: The point of the assembly isn't to try and beat the compiler via better code layout. The point is to beat the compiler by using self-modifying code, which isn't feasible with a high-level language. Without the ability to bake rarely-changed but non-constant values directly into the functions, a lot more time is spent shuffling data between registers and memory because the x86's seven registers are not enough. Via self-modification, the only memory accesses that need to occur during the inner loops are directly related to texture mapping. (A processor like the PowerPC might have enough registers that writing the assembly is pointless, since it has 32. Too bad those are a dead end in the home computer market.)
dpJudas wrote: I'm wondering what ZDoom's stance is on all of this
There is interest, but like Graf said, it needs to be selectable at run-time.
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by dpJudas »

Ah, I didn't know the assembly functions were that advanced. They certainly would have to be kept then for the palette output version.

Okay, I'll update my branch with run-time support for switching between the two modes, and then we'll see. Thanks for the feedback. :)
User avatar
Nash
 
 
Posts: 17465
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia

Re: Truecolor software rendering

Post by Nash »

Holy fuck, this came out of nowhere. :O :O :O :O Awesome work, dpJudas!
Gez
 
 
Posts: 17934
Joined: Fri Jul 06, 2007 3:22 pm

Re: Truecolor software rendering

Post by Gez »

3D floors, portals, and truecolor rendering in ZDoom? I'm running out of wishlist items here.
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by dpJudas »

Thanks guys. Glad to hear that I'm not the only one that could see some use in this feature. :)

I'm almost done with removing the compile time define, which soon should make it ready for review, testing and a formal pull request.
User avatar
Hellser
Global Moderator
Posts: 2730
Joined: Sun Jun 25, 2006 4:43 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 11/Manjaro
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Location: Citadel Station

Re: Truecolor software rendering

Post by Hellser »

Have you fixed those two issues I mentioned on IRC? (Crashing when trying to get into my native resolution and the blurry texture lines?)
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by dpJudas »

I fixed the blurry texture lines issue (how I could have missed that I dunno - maybe I need glasses). It was basically my SSE code having a big/little endian issue. The native resolution crash I'm not able to reproduce, but it might be because of the way I had hardcoded the video mode list to a few select resolutions. There is an issue with zdoom where it cuts off video modes if it finds too many are available.

I should soon have a new version ready with true color on/off toggle in place, if you'd like to help out with some more testing. :)
User avatar
Jimmy
 
 
Posts: 4725
Joined: Mon Apr 10, 2006 1:49 pm
Preferred Pronouns: He/Him

Re: Truecolor software rendering

Post by Jimmy »

This gets a big old 👍 from me. Exciting stuff. :D

Return to “Closed Feature Suggestions [GZDoom]”