Idle musing: Could you port Doom's renderer to DirectX 12?

[david_a]

Doom was created with a software 2.5D renderer. Walls/flats are not drawn as polygons and we know that looking up/down and 3D geometry can only be approximated with weird rendering hacks (discounting true portals like in Eternity/ZDoom).

Engines like GZDoom/GLBoom/Doomsday are hardware 3D renderers. There are no limitations with looking around or geometry (outside of restrictions imposed by the level format, anyway). However, since everything is drawn using a different method, there are some familiar rendering quirks that are very difficult to emulate. The most obvious is that most sprites in Doom are offset into the floor somewhat; these engines either cut off enemies feet or move them up so they look like they're floating.

Vavoom is the only example I can think of of a software 3D renderer. It attempted to graft the Quake renderer into Doom with varying success.

What's missing here is a hypothetical hardware 2.5D renderer.

As I understand it, the big deal about DirectX 12 (and AMDs Mantle, plus whatever the equivalent OpenGL version is) is that it removes a lot of the built-in abstractions and assumptions from the API and lets you access the GPU hardware far more directly. Previously, attempting to build a hardware 2.5D renderer would have been extremely cumbersome since the APIs are set up to push polygons around.

So, would it now be feasible to create a hardware 2.5D renderer?

What would the point of such a thing be? Well, uh, I'm not sure. It would certainly be novel. I don't know if it would actually be faster than doing it in software. At best, it would allow faster rendering using the good ole' 2.5D renderer that (some of us) know and love. It might allow for some odd optimizations; I would not be surprised if such a renderer would be faster with 32-bit color instead of messing around with palettes.

[Graf Zahl]

Short answer: no.

Nothing has changed about the basics of hardware rendering, it's still about pushing polygons.
What has changed is how a game engine can set up the data it wants to render, but not how the data actually looks, that's still the same.

[david_a]

Disappointing, but I guess that makes sense. I know you can do alternative rendering like raytracing on modern GPUs but I imagine that would use very similar data structures to traditional rendering.

I suppose with OpenCL/CUDA you could technically do anything you want on a GPU, but I'm not sure how branchy the Doom renderer is or how easy it would be to vectorize it. If the answers are "very" and "hard" then it would probably still be way faster running on a CPU.

[VGA]

On a slight tangent here:

Graf, as an author of the hardware renderer, isn't there a possible extension of the UDMF format or a new format that would allow for better lighting? I mean, not having lighting bleed through walls etc.

[GooberMan]

If you refer to dynamic lights, that has nothing to do with UDMF or map properties. The light occlusion system for GZDoom is effectively a backface culling solution at the moment. You don't need new UDMF data to occlude light, and precalculating such stuff would be meaningless considering they are actually 'dynamic' and not static lighting.

EDIT: Also:

david_a said:

As I understand it, the big deal about DirectX 12 (and AMDs Mantle, plus whatever the equivalent OpenGL version is) is that it removes a lot of the built-in abstractions and assumptions from the API and lets you access the GPU hardware far more directly.

Those APIs aim to remove overhead in the API layer. You still send vertices across to the GPU to process, which in turn generate pixels that need pixel shading.

[david_a]

GooberMan said:

Those APIs aim to remove overhead in the API layer. You still send vertices across to the GPU to process, which in turn generate pixels that need pixel shading.

OK. I'm still a bit fuzzy on what they do and how they relate to OpenCL/CUDA. My understanding is that the overhead they're removing are things the drivers used to do for you, so now programs are on the hook for managing a lot more low-level things (and presumably doing a better job at it since they can customize things for their own needs). I've only done a little OpenGL 12 years ago so the details are a bit beyond me.

[Graf Zahl]

Indeed.

I only can talk about GZDoom but driver overhead is enormous right now.
On my Geforce the GL driver nearly occupies an entire CPU core, fortunately it does most in its own thread so it won't impact the game.

But this is already a completely different story with AMD and Intel where driver overhead can make up 30% of the entire main thread's use of time.

And last but not least, current drivers are very poorly suited for multithreaded use, and this will also allow to use the available resources much better with these new trimmed down APIs.

[Linguica]

So GZDoom DX12-only when?

[david_a]

I wonder how much of that overhead is it being OpenGL in the first place. Is Rage the most recent major game that uses OpenGL? (Have they said what Doom 4 uses?) I doubt modern GL drivers have the same development resources assigned to them as Direct3D (at least outside of CAD drivers or whatever).

[Graf Zahl]

OpenGL is definitely worse than D3D because the API is so old and crusty. But even D3D11 suffers from the same problems, i.e. the API doesn't represent the hardware well - which is the main reason why the drivers are so inefficient.

[chungy]

Can always wait for Vulkan

[Graf Zahl]

I won't do Direct3D 12 because it suffers from the same problem as all previous versions: It requires a Windows version not everybody has.

As soon as I get my hands on a Vulkan capable driver, I'll definitely play around with it, even though I do not expect GZDoom to profit that much.

[Danfun64]

Graf Zahl said:

I won't do Direct3D 12 because it suffers from the same problem as all previous versions: It requires a Windows version not everybody has.

As soon as I get my hands on a Vulkan capable driver, I'll definitely play around with it, even though I do not expect GZDoom to profit that much.

GZDoom won't make any profit until the OpenAL branch is finalized and merged and all the build code was removed/software renderer rewritten.

Sorry, couldn't resist :P

[Guest]

Nobody wants to do a windows only port of doom.

Vulkan raises the min req of GPUs. GPUs from Opengl 3.x and DX10 era won't run it.

[kb1]

I'd like to try a hardware-accelerated engine to draw the single-sided walls and floors, and superimpose software-rendered sprites and 2-sided walls on top. That might be able to solve the sprite height problem, and allow the drawing of some of the "rendering quirks". Parts of it could be run in a separate thread for even more performance. This would be an interesting, yet challenging project. It would be difficult to clip the sprites, and not just because of the "sink into the floor" nature of software sprites. You'd also have to match the hardware renderer's math pretty closely, to even have a fighting chance.

Should be easy to mock it up, however, especially with a port that can do hardware + software.

[Jon]

Naruto9 said:

Nobody wants to do a windows only port of doom.

Except Doom Retro.

[GooberMan]

How many people actually run Doom on a non-Windows platform?

Serious question. Has there ever been a proper effort in to stat collecting for these things, or is it all just a he-said she-said community thing?

[VGA]

Most people use Windows, what is there to say? Does it matter if it's 75% or 95%?

The goal should be to make your code portable but test on Windows first and foremost. But these are hobby projects so linux-centric devs can do what they want and test what they want.

[Jon]

About 450 Debian users have prboom plus installed via the Debian package https://qa.debian.org/popcon.php?package=prboom-plus

The prvious prboom package peaked at 1000 installations.

Chocolate-doom is low at about 169.

This doesnt catch Debian users who have installed it by hand or don't have popcon enabled, nor any other Linux users.

[GooberMan]

Ah ha. That's the kind of stuff that's interesting. PrBoom is more popular with Russians, yeah? How prevalent is Linux in the Russian community compared to Windows? Windows is the dominant desktop OS, but that's not representative of the proportions that make up any community.

[snapshot]

I Really don't think it's a good idea to Port Doom's renderer to dx12, since not all people moved to Win10 and DX Doesn't change anything besides being easier to use for devs .

[Guest]

There is DX 11.1 - 11.3 which is closer to DX12 without requiring DX12.

But if ppl really want real 3D geometry, then it's better to use a modern map format that breaks compatibility with vanilla doom then.

[Csonicgo]

Jon said:

Except Doom Retro.

Even that's no longer the case; Doom Retro runs better than the Windows version on Linux now.