VOGONS


First post, by blueclouds8666

User metadata
Rank Newbie
Rank
Newbie

I've been doing a research in relation to OpenGL and different, alternative rendering methods. I've found several libraries (based on DirectX Wrapping and Software rendering) that, even thought some are very old, can be quite useful for fixing compatibility problems that happen with old OpenGL games such as for example Unreal, Unreal Tournament 99, Return to Castle Wolfenstein, the Quake saga, DOOM source ports... It seems these kind of issues are more usual nowadays than i initally thought. Those libraries (GLDirect, AltOGL, Mesa3D) are fully compatible with modern hardware, as well as Windows 7, 8.1 and later.

Additionally, several libraries can add graphical enhancement to the rendering pipeline, and very specially, natively forced MSAA anti-aliasing, a great improvement very little known by the videogame community. (This method is different to in-engine implementations, NVIDIA Control Panel settings or NVIDIA Inspector). Said library is QeffectsGL, available here: https://github.com/crystice-softworks/QeffectsGL

If you are interested, please chech the full published document on my website:
http://neonfloppy.sytes.net/articles/2021-opengl/

I also want to specially thank you, the VOGONS forum community, for being such a vast source of knowledge for this kind of stuff. Probably this research would be lagerly incomplete if it wasn't for this place. You probably are wise enough to know most part of this stuff but i nevertheless find it interesting to revise, document it for the future, and for less knowledgable people out there that don't know about this.

Reply 1 of 7, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I am sorry to say that the statement of Intel UHD 620 failed to provide proper OpenGL support is wrong. If any Intel Graphics engineers read it, then they would just have a good laugh. If you have meant to engage in proper technical discussion, then you could have done more thorough research, just as an example, scrutinize the faulty games under debugger to understand the cause of crash. Then, you would have made a more respectable conclusion.

GLDirect, AltOGL and Mesa3D could be your solution. However in my opinion, those are poor solution. If you had NVIDIA or AMD GPUs (or APUs), then none of them were required. Intel could have done the same if they valued game compatibilities. They could have made a business decision not to, since those were very old legacy OpenGL games.

Reply 2 of 7, by blueclouds8666

User metadata
Rank Newbie
Rank
Newbie
kjliew wrote on 2021-06-20, 19:37:

I am sorry to say that the statement of Intel UHD 620 failed to provide proper OpenGL support is wrong. If any Intel Graphics engineers read it, then they would just have a good laugh. If you have meant to engage in proper technical discussion, then you could have done more thorough research, just as an example, scrutinize the faulty games under debugger to understand the cause of crash. Then, you would have made a more respectable conclusion.

GLDirect, AltOGL and Mesa3D could be your solution. However in my opinion, those are poor solution. If you had NVIDIA or AMD GPUs (or APUs), then none of them were required. Intel could have done the same if they valued game compatibilities. They could have made a business decision not to, since those were very old legacy OpenGL games.

I agree that my research could have been deeper in that regard, properly debugging those old games, but that would for obvious reasons take considerably more time to do; a limited resource i have to carefully manage, and as much as i would want to, the time i can spend in my projects is also limited. My intent is to provide acessible and useful articles, not excessively technical or advanced as that would vastly narrow the amount of readers that would understand it or find it an interesting read. I guess, understandably, It is very difficult to content everyone, and i'm sorry If my article didn't met the technical preciseness expected.

I also want to note that, after all, this is just an article, and in some manner or other it might reflect my opinion and personal experiences, something i often try to keep it at a low. This is a purely non profit project of mine, trying to offer a tiny bit of knowledge to the rest of the people, and i'm sharing my efforts with this community and others in case anyone finds it any useful, and if that's the case for someone, i'm already happy with just that.

Reply 3 of 7, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie

A lot of problems with old OpenGL games is either drivers failing to provide emulation for legacy features, not limiting the GL_EXTENSIONS string and triggering buffer overflows, or erroneously reporting extensions that don't actually function properly that can result in undefined behaviour in the game engine's renderer.

Intel Graphics is weird, generally from my experience the Windows drivers are extremely hit and miss, mostly miss. On Linux however, they are more robust and feature rich even if a feature in particular must be implemented through software emulation. (and the software emulation tends to be... somewhat faster?)

My PC (a NUC6i7KYK) has a Iris Pro 580 integrated, and somehow 16-bit dithering exists so various 16-bit only Direct3D and OpenGL games render with dithered graphics rather than non-dithered heavily banded graphics. A good example is the old LithTech games, I've never had a single rendering error in all of Shogo or Blood 2 on this system, even on the latest Mesa and Linux 5.12.x.

I still have to use environment variables to forcefully cut down on the reported number of GL_EXTENSIONS to prevent buffer overflows in older games like Quake 2, Soldier of Fortune (and 2), etc. I sometimes even have to go as far as to override the entire reported GL version back to 1.2 in addition to limiting the extension year to 1998.

“I am the dragon without a name…”
― Κυνικός Δράκων

Reply 4 of 7, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie

Neat, I'll have to check this out. Serious Sam FE has some weird graphical issues with opengl in windows. The D3D render looks fine, but because it is running through compatibility layers the performance suffers a lot. I'll have to give this a try.

Reply 5 of 7, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
blueclouds8666 wrote on 2021-06-20, 19:01:

I've been doing a research in relation to OpenGL and different, alternative rendering methods. I've found several libraries (based on DirectX Wrapping and Software rendering) that, even thought some are very old, can be quite useful for fixing compatibility problems that happen with old OpenGL games

DracoNihil wrote on 2021-06-24, 17:10:

A lot of problems with old OpenGL games is either drivers failing to provide emulation for legacy features, not limiting the GL_EXTENSIONS string and triggering buffer overflows, or erroneously reporting extensions that don't actually function properly that can result in undefined behaviour in the game engine's renderer.

I wonder what portion of these problems is really caused by faulty drivers and incompatible hardware, and how much is caused by bugs in the games themselves.
I'm not an OpenGL expert by any means but I've read an OpenGL specification or two, and most of the time I see an online OpenGL tutorial, I find something questionable, half true, or even wrong, indicating that someone hasn't read the spec.

Reply 6 of 7, by vlad54rus

User metadata
Rank Newbie
Rank
Newbie
mothergoose729 wrote on 2021-06-24, 17:21:

Neat, I'll have to check this out. Serious Sam FE has some weird graphical issues with opengl in windows. The D3D render looks fine, but because it is running through compatibility layers the performance suffers a lot. I'll have to give this a try.

What kind of glitches?
The only one i've seen on Intel graphics was "wavy geometry" caused by lack of depth buffer precision. That one can be resolved by explicitely setting bit depth with a console command gap_iDepthBits = 24 and then ApplyVideoMode().

Reply 7 of 7, by mothergoose729

User metadata
Rank Oldbie
Rank
Oldbie
vlad54rus wrote on 2021-07-01, 07:02:
mothergoose729 wrote on 2021-06-24, 17:21:

Neat, I'll have to check this out. Serious Sam FE has some weird graphical issues with opengl in windows. The D3D render looks fine, but because it is running through compatibility layers the performance suffers a lot. I'll have to give this a try.

What kind of glitches?
The only one i've seen on Intel graphics was "wavy geometry" caused by lack of depth buffer precision. That one can be resolved by explicitely setting bit depth with a console command gap_iDepthBits = 24 and then ApplyVideoMode().

It's the same one. I'll have to see if I can do the same thing for my nvidia GPU.

A lot of times theses errors are fixable, it is just figuring out what is wrong and how you fix it takes a lot of time and effort and even luck.