ZDoom

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.

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.

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.

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.

Hey, just as an FYI, this would be a good opportunity to finally do something with [wiki=CVARs:Display#vid_defbits]vid_defbits[/wiki], 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.

Just curious to know, but could it be possible to implement also the 16-bit color version?

Why? It'd provide no advantage over 32 bit, not even performance.

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.

You can use something like ZDL if in doubt. http://zdoom.org/wiki/ZDL

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.

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.

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).

Tried to compile with the recent Clang, got bunch of similar errors: This is how __m128i is defined: 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.

See! Told you my SSE skills sucked. OK, looking into fixing this.

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.