Hardware Not Supported Rainbow Six Siege Vulkan
Matty Fiedler
OpenGL, Vulkan, and DirectX are backends that allow to render and display things more efficiently. OpenGL and Vulkan are cross-platform, while DirectX is Microsoft-only. Putting SoftPoly in the middle, however, tells me this isn't the answer you're looking for. Because you're specifically referring to GZDoom here, aren't you?
So the first thing to do is to explain there are two steps to bring things to life on your screen: the first step is rendering it, basically get the computer to figure out how it should look like. The second step? Displaying it. The image has been computed, now actually put it on the screen.
For the second step, well, if you render with OpenGL, you display with OpenGL. If you render with Vulkan, you display with Vulkan. No choice here, it would be stupid to use a different backend. So it's only if you use a software renderer (classic or softpoly) that you get to choose between OpenGL, Vulkan, or DirectX. But as far as image quality goes, it shouldn't change much to use one instead of another here, since they don't render the image, they just display it at this point.
I'm specifically referring to both GZDoom and Doom 64, since they both have backends like Vulkan and OpenGL. Though Doom 64 doesn't seem to have a software renderer that I can think of, at least with the official port. But for clarity, if I'm running the Vulkan backend, choose "Hardware Accelerated" in the software render options?
With the new Doom64 port in Kex3, things are divided up into RHIs (Rendering Hardware Interface), to which there's actually 4; DirectX11 (with 10.0 compatibility support), OpenGL 3.2, Vulkan and GNM. However there's only 1 renderer which is unique to Doom64, the RHIs act as an abstraction layer between it and the desired graphics API. They even run the same shaders (in terms of code, they are compiled into different shader binaries of course).
This means in an ideal situation, there is no difference, they should all act the same and visually they should all be expected to produce identical results. However the actual difference will be defined by your hardware and driver compatibility. Your Graphics drivers may support everything in OpenGL3.2 but not Vulkan, or your hardware may be more optimised to run Vulkan and thus perform faster than OpenGL.
Because the renderer doesn't actually know what RHI it's running on, you could in theory make a software driven RHI as well. However this would not be the same as Doom's original renderer, which Doom64 no longer supports.
Actually that's very close to how the Vulkan, OpenGL, and SoftPoly selection works in GZDoom. With SoftPoly basically being that software RHI. There's otherwise a large chunk of "hardware renderer" code that's shared between the three of them.
This is of course independent from the Carmack software renderer which can use any of those three as a rendering target. When using SoftPoly with the Carmack software renderer this effectively becomes a Direct3D target on Windows.
For most people, yes if you have Vulkan hardware you should use Vulkan and use the hardware accelerated renderer. There are people like myself that prefer use the classic renderer with all it's little quirks, so this is ultimately a personal preference.
I'm not aware of any hardware where OpenGL is the better choice unless Vulkan just isn't supported, but in some cases it might be faster at throwing the Carmack renderer onto the screen than Vulkan (depends entirely on your drivers). SoftPoly in "hardware accelerated" mode (which isn't actually accelerated) is mostly a curiosity, but due to the use of Direct3D it can for some hardware be the fastest way to throw the Carmack renderer to the screen. It's more of a last resort fallback though.
Yes. It is the same renderer code from the original game, just heavily modified and expanded. You can tweak the hardware accelerated renderer to look aesthetically very close to the original game though these days, but things like the way sprites are drawn is still wrong. The Carmack renderer doesn't have these issues since it's still following the way the original code worked. The flip side is you have to deal with things like limited support for free look because the renderer is just incapable of changing the camera pitch by design.
Actually that's very close to how the Vulkan, OpenGL, and SoftPoly selection works in GZDoom. With SoftPoly basically being that software RHI. There's otherwise a large chunk of "hardware renderer" code that's shared between the three of them.
Huh, really? When I looked at it initially it seemed like different code paths entirely, outside the usual setup in d_display. There was also this weird stuff going on like all the assets in vulkan memory being upside down (instead of the screen itself which is what would normally be the case.)
The stuff in src/common/rendering/hwrenderer and src/rendering/hwrenderer should all be shared amongst Vulkan, OpenGL, and SoftPoly. My understanding is this includes, among other things, everything about determining what polygons to draw. Just the stuff in src/common/rendering/gl,polyrenderer,vulkan should be specific. Keep in mind though that I personally have no investment in the hardware renderers so you might be able to find a counter example, but that's the gist of it. You guys may or may not have a more complete abstraction I really can't say. But your high level description fits both projects just fine.
For the hardware accelerated renderer, the big thing is to change the sector light mode to Software or Vanilla. Software is supposed to match the lighting you see when you set render mode to Doom Software Renderer (or the true color sw renderer). The vanilla mode is supposed to be closer to vanilla since if I recall correctly the algorithm for determining the lighting was resolution dependent and it turned out ZDoom didn't fix that issue correctly or something like that.
d3342ee215