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.

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.

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.

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.

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.

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

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.