"High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Support for running, installing or compiling OpenMW

Before you submit a bug report for the first time, please read: Bug reporting guidelines
Post Reply
Brothenjoyer
Posts: 2
Joined: 12 Oct 2021, 21:04

"High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by Brothenjoyer »

Hi all,

I recently installed OpenMW 0.46.0 on a fresh install of Windows 10. I noticed that, while using my CPU's integrated graphics, I could only pull 30 FPS in exteriors, so in Windows 10's Display settings, I changed OpenMW to use 'High Performance' (aka: my GPU) instead of my CPU, thinking that would solve the issue.

However, attempting to start OpenMW with this setting enabled causes the program to freak out on startup. The screen is completely black, and the cursor is changed to a purple dot. After a few seconds of being stuck like this, the game crashes to desktop.

It still runs fine using my integrated CPU, but I'd really like to get more than 30 FPS. I have no mods of any kind installed, and Tribunal and Bloodmoon are both installed in the correct order. My graphics card is an AMD Radeon 7800 with the most recent drivers installed. Underclocking my GPU with MSI Afterburner hasn't done anything to solve the problem, either.

Any ideas on what might be going wrong? I've searched high and low but haven't run into anyone else having this problem.

Thanks!
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: "High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by AnyOldName3 »

Can we have your log, please? You can find it with https://openmw.readthedocs.io/en/latest ... paths.html. This puts me in mind of another issue I've seen, but that's been for people using their Intel GPU when they've also got an Nvidia one, so not quite the same.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: "High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by AnyOldName3 »

That looks like the same problem. I'd definitely like to get to the bottom of it, but so far, no one's gone through the steps to get me the information I need. They're posted here: https://old.reddit.com/r/OpenMW/comment ... 0/grqkotb/.
Brothenjoyer
Posts: 2
Joined: 12 Oct 2021, 21:04

Re: "High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by Brothenjoyer »

OpenMW CTD'd while it was loading before it could get to and exit the main menu, but otherwise I followed all the steps. Here's the contents of LOG: https://pastebin.com/MxQZxGqh

LO2 was empty. Should I be using something other than notepad to try and open it?
Last edited by Brothenjoyer on 14 Oct 2021, 03:38, edited 1 time in total.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: "High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by AnyOldName3 »

For future reference, until the forum software's decided you're definitely human, your posts won't show up until someone manually approves them (and if you edit the visible ones, they'll turn invisible again). You don't need to post things more than once.

As for the actual problem, it looks like somehow OpenMW's being given Microsoft's super-basic software implementation of OpenGL instead of the one from the drivers for your HD 7800. I'm looking into why that might possibly have happened, but it's really weird.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: "High Performance" GPU Setting Causes Crash On Startup (Windows 10, 0.46)

Post by AnyOldName3 »

In terms of getting you a working OpenMW installation, switching to one of the 0.47 release candidates or one of the 0.48 development builds will sort the problem out.

In terms of why this is happening, and whether it's our fault and could appear with OSG 3.6.x, it looks like there was a big overhaul of context creation on Windows between OSG 3.4.1 and 3.6.x to make it support emulated GLES via ANGLE, which uses EGL instead of WGL. Presumably either the refactor destroyed the bug or the testing that went with it fixed it. I'm sufficiently convinced that this won't happen with modern OSG versions that I don't think we need to invest much time into tracking down how it was breaking and whether it's OSG's fault or ours.
Post Reply