OpenGL Driver Not Accelerated! [Resolved]

[ReX]

Thank you all for the various explanations. The way I understand it, GZDooM's manifest is checking for compatibility with a specific operating system (in this case, Win 10). Because of some defects in Intel's drivers, GZDooM is unable to recognize the operating system and, thereby, the version (or, perhaps, even the presence) of OpenGL. The WTFI utility rewrites some parts of the GZDooM manifest that then allows GZDooM to check the box for Win 10 compatibility. At this point it appears that my best bet is to run the WTFI utility as outlined in the other thread about this issue.

I also gathered that drfrag has made a modification that obviates the need for the WTFI utility. Any idea when the changes will go into effect in a usable executable of GZDooM?

[Graf Zahl]

Not quite.

GZDoom declares in its manifest that it knows Windows Vista, 7, 8, 8.1 and 10.
But Intel's driver apparently has a broken version check and does not like the 10 that Windows 10 returns. IMO it's utterly pathetic that they haven't bothered to release a hotfix, it's not like these old chipsets are generally obsolete.

[ReX]

@ Graf: I think I understand. What about the apparent fix that drfrag mentioned?

TAt this point it appears that my best bet is to run the WTFI utility as outlined in the other thread about this issue.

In the ongoing saga .... I downloaded wtfi.exe and tried dragging gzdoom.exe on it. I get the message: "This app can't run on your PC... etc." I created a batch file and tried to run it (wtfi gzdoom.exe) and it returned: "Unsupported 16-Bit Application .... incompatibility with 64-bit version of Windows... etc."

At this point, my best bet appears to be to wait for drfrag's fix. ["Help me doctor frag; you're my only hope!"]

[drfrag]

With my change i target win 8.1 instead of 10 in the legacy builds (i declare compatibility with 8.1) and i can't distinguish between the two, not that many of us are still using 8.1. I've uploaded a devbuild, check the lzdoom thread. For modern GZDoom you need the utility, but i doubt you can run it. If your card supports only 3.1 you can't. LZDoom had the gl_riskymodernpath CVAR for 3.1 cards.

[ReX]

@drfrag: Got it, thanks.

Meanwhile, I found a link to what is probably a newer version of wtfi.exe and ran it. It worked, but when I ran GZDooM I got: "Unsupported OpenGL version. At least OpenGL is required to run GZDooM. For older versions .... vintage build of GZDooM." This is consistent with what you said, drfrag. And it brings me one step closer to being able to run GZDooM.

[Rachael]

@ ReX:

https://mega.nz/#!tN8yXIoL!tXpKlwKFw8-O ... 6OJo6xs5Wc

This is GZDoom 4.3.3 32-bit, WTFI'd.

(edit: might not work though, since you said the tool itself already failed you)

[ReX]

@Rachael: Thanks. But the version I need is a 64-bit one. [All is good, however, as drfrag helped me out via PM.]

[Rachael]

Ah, sorry, I thought the incompatibility warning was attempting to run a 64-bit on 32-bit system.

[drfrag]

So as expected the devbuild works. To run modern GZDoom you need to select the SoftPoly backend.

[Blzut3]

If the theory is it's just the version check wouldn't the Windows compatibility mode be enough to fix it? I assume it was tried, but I don't see a mention of this in the relevant threads so just curious.

But Intel's driver apparently has a broken version check and does not like the 10 that Windows 10 returns. IMO it's utterly pathetic that they haven't bothered to release a hotfix, it's not like these old chipsets are generally obsolete.

Keep in mind that Intel does not support Sandy Bridge's iGPU on Windows 10 at all. There just happens to be a driver, and about all I can say about it (having played around with overclocking a Celeron G470) is that at least there's some acceleration even if it's buggy. Microsoft didn't even try to force Windows 10 upgrades on people running Sandy Bridge iGPU.

Which is a shame since otherwise Sandy Bridge machines are still good, but neither AMD nor nvidia's GL3/DX10 cards are supported on Windows 10 either so no too surprising. Especially since Ivy Bridge forward is technically capable of Vulkan on Linux.

[Graf Zahl]

Which is a shame since otherwise Sandy Bridge machines are still good, but neither AMD nor nvidia's GL3/DX10 cards are supported on Windows 10 either so no too surprising. Especially since Ivy Bridge forward is technically capable of Vulkan on Linux.

For Intel that limitation is a lot worse, though, because if you got a dedicated graphics card, it can be replaced - the on-board chip can not.

[drfrag]

But for laptops dedicated "cards" are usually soldered on the motherboard.
The compatibility mode shoulf fix it now that you mention it, but since _mental_ made the tool may be not. Anyway how do you know you must run it in compatibility mode?

[Blzut3]

For Intel that limitation is a lot worse, though, because if you got a dedicated graphics card, it can be replaced - the on-board chip can not.

As drfrag said, for laptops it makes no difference since it's soldered down anyway. Only thing is Sandy Bridge laptops were usually paired with Fermi or Terrascale 2 dGPUs both of which are GL4/DX11 GPUs which support Windows 10. Sandy was basically the end of Intel being behind everyone else on API support.

Anyway how do you know you must run it in compatibility mode?

This question makes no sense given the sentence it follows? I don't, I just know compatibility mode changes the version number Windows reports so it sounds like it should work.

[Rachael]

Anyway how do you know you must run it in compatibility mode?

This question makes no sense given the sentence it follows? I don't, I just know compatibility mode changes the version number Windows reports so it sounds like it should work.

The fix drfrag put in where it denies the ability to detect Windows 10 is exactly that fix.

[Blzut3]

The fix drfrag put in where it denies the ability to detect Windows 10 is exactly that fix.

I know that, I'm just curious if anyone tried the simple solution that isn't "change the binary to not know about Windows 10." Like drfrag I assume the answer is yes since _mental_ wrote that tool, but since I wasn't able to find any relevant threads talking about compatibility mode not working I can't rule out that we all forgot about the obvious method built into Windows.