[Closed] Truecolor software rendering

Moderator: Developers

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 03, 2016 5:17 am

Okay, I've finished my work on the branch and it should be ready for testing and review.

I've created a win32 binary for it which can be downloaded here: http://esoteric.clanlib.org/~mbn/zdoom-truecolor.zip
The pull request for this: https://github.com/rheit/zdoom/pull/670

True color mode can be toggled on and off via the new 'True color output' in the Display options. Note that it defaults to off, so you'll have to enable that first before seeing anything different. My win32 binary also changes the list of video modes available to a fairly short list of common modern monitor resolutions (1080p, 27", 30", 4k, 5k, 34" ultra widescreen). This isn't part of the pull request.

Please let me know what you think. :)
User avatar
dpJudas
Cookies for cookie monster!
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Graf Zahl » Fri Jun 03, 2016 5:44 am

I did a quick check. Performance drops about 30-40% depending on the map, but that's to be expected.

But it doesn't compile as 64 bit, because dovline4 is a #define there.
I think you would be better qualified to have a look and change it so that it works, too.

Last but not least: Do you have any ideas to enhance this by allowing to draw with arbitrary palettes and true color textures? That'd be the icing on the cake.
User avatar
Graf Zahl
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby edward850 » Fri Jun 03, 2016 6:02 am

Some quick observations:
  • Slopes don't work, even less so than the 8bit renderer currently. They just become a grey void.
  • Fog doesn't seem to work either.
  • You are missing some columns in transparency rendering.
  • There's no true-colour translation support, which would be expected. Set your player colour to cyan, then chasecam.
  • Likewise with sector colours. "testcolor 00ffff" for an example.
  • There's a crash triggered in some situations, not sure exactly what causes it. Observable in Demo.wad where you first head outside into the foggy area, then turn back towards the tunnel; Cybercrime3.wad, just start map01 and move around a tad.
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 03, 2016 6:16 am

Okay, fixed that it was a define on 64 bit. Need to figure out why my cmake isn't generating any 64 bit targets.

Enhancing it to draw true color textures should be possible - from the drawers point of view it would probably only make them faster because they wouldn't have to do the palette lookup. It mostly comes down to how much work it requires to get the GetColumn function to return bgra8 data and adjusting the code that offsets into the data. I'll have to take a closer look at the GetColumn part of the codebase. :)
User avatar
dpJudas
Cookies for cookie monster!
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Gez » Fri Jun 03, 2016 6:38 am

Hey, just as an FYI, this would be a good opportunity to finally do something with vid_defbits, which has existed in the engine for years despite not toggling anything. In any case, the CVAR for toggling truecolor on/off, if not vid_defbits, should at least have a vid_ (or possibly r_?) prefix.
Gez
 
Joined: 06 Jul 2007

Re: Truecolor software rendering

Postby Edward-san » Fri Jun 03, 2016 2:33 pm

Just curious to know, but could it be possible to implement also the 16-bit color version?
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: Truecolor software rendering

Postby Graf Zahl » Fri Jun 03, 2016 2:48 pm

Why? It'd provide no advantage over 32 bit, not even performance.
User avatar
Graf Zahl
 
Joined: 19 Jul 2003
Location: Germany

Re: Truecolor software rendering

Postby dpJudas » Fri Jun 03, 2016 3:28 pm

Thanks for the feedback, edward850. I've tracked down the transparency rendering bug you found and fixed it.
The translation and fill color support is currently working as intended. Improving this part requires that I understand better when translation and solid color fills happens. For the time being it seemed the most safe way to just fall back to palette look up when in doubt. Especially as I did not want to risk breaking the 8 bit renderer by making too many changes at the same time.

How do I open the demo.wad? I tried adding -file demo.wad to the command line, but this didn't seem to do the trick. Sounds like the crash might be related to fog.

About vid_defbits - I'm ok with using whichever naming convention you guys prefer for the CVAR. I chose the plain undecorated name mostly because that was what 'fullscreen' used and I wasn't sure if this would be a vid or a render property. It probably is more a video property than a render property as it configures which format the video output (d3d9/sdl/cocoa) advertices to the software renderer. IMHO a boolean setting is more logical than using the numbers 8 and 32.

I think Graf is right about the 16 bit thing. There's no real point there - the SSE code can't even pack natively to 16 bit, so it would probably be slower.
User avatar
dpJudas
Cookies for cookie monster!
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby Major Cooke » Fri Jun 03, 2016 3:30 pm

You can use something like ZDL if in doubt. http://zdoom.org/wiki/ZDL
User avatar
Major Cooke
"Shit happens, but I'd love it if it didn't." -AEoD Team
 
Joined: 28 Jan 2007

Re: Truecolor software rendering

Postby edward850 » Fri Jun 03, 2016 3:31 pm

dpJudas wrote:How do I open the demo.wad? I tried adding -file demo.wad to the command line, but this didn't seem to do the trick.

Make sure demo.wad is in ZDoom's working directory, and launch it with Doom2.
Major Cooke wrote:You can use something like ZDL if in doubt. http://zdoom.org/wiki/ZDL

Not if he needs it in a debugger.
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Truecolor software rendering

Postby Major Cooke » Fri Jun 03, 2016 3:39 pm

If he uses VS he can, via Attach To Process after starting ZDoom. Though if it's crashing at start-up, yeah that might be a bit more troublesome.
User avatar
Major Cooke
"Shit happens, but I'd love it if it didn't." -AEoD Team
 
Joined: 28 Jan 2007

Re: Truecolor software rendering

Postby dpJudas » Sun Jun 05, 2016 6:53 am

Thanks for the help on how to launch the demo wad.

I've fixed the fog crash and improved how the renderer handles FDynamicColormap (fog and testcolor). It comes with a bit of performance drop in true color mode when a dynamic colormap is active. Mainly that my SSE/assembly abilities are so poor that I could not figure out how to effectively write the SSE. The code dealing with this is written as a define that is used in all the various SSE drawers:

- https://github.com/dpjudas/zdoom/blob/m ... ain.h#L224 <- the define itself (the intensity part is what I'm unhappy about)
- https://github.com/dpjudas/zdoom/blob/m ... ain.h#L139 <- the C code doing the same thing, for reference on what the intrinsics are trying to do

Hopefully someone more skilled in the art of SSE will be able to optimize this better. In any case, it works with the version I have - just at about 60% the frame rate as when there's no dynamic colormap active. I've uploaded a new executable if anyone wants to play around with it: http://esoteric.clanlib.org/~mbn/zdoom-truecolor2.zip

I'm not going to attempt adding the 32bpp texture support at the moment. Pretty exhausted toying with the drawers for now. Please let me know if you see any additional rendering bugs (that isn't in zdoom's main branch). :)
User avatar
dpJudas
Cookies for cookie monster!
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby _mental_ » Sun Jun 05, 2016 7:31 am

Tried to compile with the recent Clang, got bunch of similar errors:
Code: Select allExpand view
src/r_draw.cpp:2141:5: error: member reference base type '__m128i' (vector of 2 'long long' values) is not a structure or union                               
                                SSE_SHADE(fg, shade_constants);
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/r_main.h:229:41: note: expanded from macro 'SSE_SHADE'
        uint16_t intensity_hi0 = ((intensity_hi.m128i_u16[2] + intensity_hi.m128i_u16[1] + intensity_hi.m128i_u16[0]) >> 8) * shade_constants.desaturate; \
                                   ~~~~~~~~~~~~^~~~~~~~~~

This is how __m128i is defined:
Code: Select allExpand view
typedef long long __m128i __attribute__((__vector_size__(16)));

Apparently this type doesn't have any fields. I doubt this will work with any compiler except MSVC.
Also, this MSDN article has the following remark:
You should not access the __m128i fields directly.
_mental_
 
Joined: 07 Aug 2011

Re: Truecolor software rendering

Postby dpJudas » Sun Jun 05, 2016 9:05 am

See! Told you my SSE skills sucked. :) OK, looking into fixing this.
User avatar
dpJudas
Cookies for cookie monster!
 
Joined: 28 May 2016

Re: Truecolor software rendering

Postby _mental_ » Sun Jun 05, 2016 9:09 am

dpJudas wrote:See! Told you my SSE skills sucked. :) OK, looking into fixing this.

The only problem I see is that the compiler doesn't warn about bad and non-portable usages.
_mental_
 
Joined: 07 Aug 2011

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: Ahrefs [Bot], D2JK and 1 guest