The only reason Paranoia has a custom opengl32.dll is because they didn't know how to achieve things without it. Everything they did with a modified opengl32.dll was entirely possible with the original one, by using proper graphics programming techniques.
They did 3 things: added a stencil buffer, added an alpha buffer and modified the depth range. The alpha buffer was, interestingly, used to support really old GeForce graphics cards, in terms of storing render data for dynamic lights. There are other ways to do that without using a hacked DLL.
But the funniest thing of all is, the stencil buffer was "needed" to prevent the flashlight texture from tiling itself, which was actually easily fixable without a custom DLL.
Here's an illustration:
Normal, with clamping to edges Without clamping to edges Instead of modifying opengl32.dll, they could've just used a simple flag for the texture:
GL_CLAMP_TO_EDGE
with, of course, a completely black border around the texture itself.
Here are 4 different options for texture wrapping:
Taken from
here.
The depth range modification was unnecessary, because they could've used some maths to adjust the depth values on the receiving end.
In case you're wondering, this is depth:
Black = close to the camera, white = far from the camera These values go between 0.0 and 1.0, and it is generally used to blend fog, soft particles and such. I don't know how Paranoia's renderer utilised it, but editing the DLL was needless.
If you want to improve performance in Xash3D, or any HL mod, really, you have to learn about graphics programming with OpenGL. If you have access to Xash3D's source code, you can probably do some smaller optimisations without rewriting the renderer.
Otherwise, if you want a 2x, 3x, 5x improvement in framerates, you need to have quite some experience in modern OpenGL or Vulkan. The most ideal one IMO would be OpenGL 3.x.
One misconception is that rendering APIs like DirectX, OpenGL, Vulkan etc. automatically just render your frames and whatever you throw at them. People think they're like "plug'n'play", but no, they're not. Instead, you are the one who defines how OpenGL will work. You tell it how to render the triangles etc. There are many, many functions that the API provides to you, and you can use it. You are wrestling with your graphics card, yelling at it how to render your stuff.
The problem is, GoldSrc's renderer uses OpenGL in so-called immediate mode. And I've probably talked about this 120 times on TWHL Discord, but here's how immediate mode rendering works: (in a very very simplified way)
- you tell OpenGL to "begin" rendering
- you send texture data, vertex data (vertex positions, UV coordinates etc.)
- you tell OpenGL to "end" rendering and wait for the next frame
The thing is, the CPU is
always sending rendering data to the GPU, every frame. The GPU receives the polygons, the textures etc., but it immediately "forgets" it the next frame. This is reason #1 why GoldSrc and Xash3D can perform poorly with many wpolys and even more epolys. Of course, in the late 90s, video cards were built for immediate mode, so logically, it was the only option.
But, it's an issue today and it'll be an issue for God knows how long, because modern GPUs have to emulate this mode. Modern GPUs are built for something else, called retained mode.
Retained mode works this way:
- upload data to the GPU's video memory (preferably when the map starts), and it stays there
- render them and wait for the next frame
When you're not sending all the data every frame, you can theoretically render the entire map at 200fps, lol.
So, if you want better fps, learn graphics programming and rewrite a part of, if not the whole renderer to work more efficiently. Otherwise, don't make high-poly models.