Oolite on HDR Displays

[phkb]

I sure hope it doesn't have anything to do with build 26100.4770. I am still running on 26100.4652.

I should add, the update to 26100.4770 happened this morning, between the successful attempt yesterday, and the failed ones today.

[another_commander]

Can you please post the output from dxdiag while in HDR mode?

[phkb]

Here you go: DxDiag.txt

TL;DR - Display 2 says HDR is supported.

[another_commander]

Can you please try this build? https://www.filemail.com/d/esdmlwamsnvzinm

I added some additional logging when HDR setup fails to try to pinpoint the cause.


Edit: I also updated my system to 26100.4770. All good with HDR detection here including after restarts, the Windows build is not the problem.

[phkb]

I'm not seeing anything additional in the log. I'm assuming it's at the same spot as the checking availability line?

Code: Select all

20:12:19.336 [gameView.isOutputDisplayHDREnabled]: HDR display output requested - checking availability: NO
20:12:29.107 [display.initGL]: Requested a new surface of 1920 x 1080, fullscreen.
20:12:29.177 [display.initGL]: Created a new surface of 1920 x 1080, fullscreen.
20:12:29.240 [startup.complete]: ========== Loading complete in 16.71 seconds. ==========
20:12:30.178 [debugTCP.connected]: Connected to debug console "DebugConsole".
20:12:39.839 [exit.context]: Exiting: Exit Game selected on start screen.
20:12:39.842 [gameController.exitApp]: .GNUstepDefaults synchronized.

Closing log at 2025-07-23 20:12:39 +1000.

Another log snippet, in case it helps:

Code: Select all

Opening log for Oolite version 1.91 (x86-64 test release) under Windows 10.0.26100.4770  64-bit at 2025-07-23 20:12:11 +1000.
12th Gen Intel(R) Core(TM) i5-12400F 12 processors detected. System RAM: 32619 MB (free: 18639 MB).
Build options: OpenAL, GLSL shaders, new planets, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

20:12:12.352 [dataCache.rebuild.explicitFlush]: Cache explicitly flushed with always-flush-cache preference. Rebuilding from scratch.
20:12:12.623 [process.args]: Startup command: C:\Oolite-Trunk\oolite.app\oolite.exe -hdr 
20:12:12.778 [display.initGL]: V-Sync requested.
20:12:12.778 [display.mode.list.native]: Windows native resolution detected: 1920 x 1080
20:12:12.778 [display.initGL]: Trying 16-bpcc, 24-bit depth buffer
20:12:12.976 [gamma.set.failed]: ----- WARNING: Could not set gamma: Gamma ramp manipulation not supported
20:12:12.976 [display.initGL]: Achieved color / depth buffer sizes (bits):
20:12:12.976 [display.initGL]: Red: 16
20:12:12.976 [display.initGL]: Green: 16
20:12:12.976 [display.initGL]: Blue: 16
20:12:12.976 [display.initGL]: Alpha: 16
20:12:12.976 [display.initGL]: Depth Buffer: 24
20:12:12.976 [display.initGL]: Pixel type is float : -1
20:12:12.976 [display.initGL]: Pixel format index: 89
20:12:13.132 [joystick.init]: Number of joysticks detected: 1
20:12:13.135 [rendering.opengl.version]: OpenGL renderer version: 4.6.0 ("4.6.0 NVIDIA 576.88"). Vendor: "NVIDIA Corporation". Renderer: "NVIDIA GeForce GTX 1660/PCIe/SSE2".

[another_commander]

It looks like the failure happens even earlier in detection. Could you give this one a spin and check the log for "checkpoint #x" messages?

https://www.filemail.com/d/pnunnxzfprqywlc

[phkb]

Here's the result:

Code: Select all

21:49:39.927 [MSAA.setup]: Multisample anti-aliasing requested.
21:49:40.352 [shipData.load.begin]: Loading ship data.
21:49:48.543 [unclassified.MyOpenGLView]: Failed at checkpoint #1
21:49:48.543 [unclassified.MyOpenGLView]: Failed at checkpoint #3
21:49:48.543 [unclassified.MyOpenGLView]: Failed at checkpoint #4
21:49:48.543 [gameView.isOutputDisplayHDREnabled]: HDR display output requested - checking availability: NO
21:49:51.465 [display.initGL]: Requested a new surface of 1920 x 1080, fullscreen.
21:49:51.536 [display.initGL]: Created a new surface of 1920 x 1080, fullscreen.
21:49:51.615 [startup.complete]: ========== Loading complete in 14.66 seconds. ==========

[another_commander]

It fails on monitor detection apparently. Here is one (hopefully last) test exe with even more logging.

https://drive.google.com/file/d/1sjcXHw ... sp=sharing

[phkb]

Code: Select all

22:51:11.201 [unclassified.MyOpenGLView]: Failed at checkpoint #1. monitorDevicePath: \\?\DISPLAY#MSI4BA9#5&1a66a0b3&0&UID4354#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}, wcsDeviceID: \\?\DISPLAY#ACR0BAC#5&1a66a0b3&0&UID4353#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
22:51:11.201 [unclassified.MyOpenGLView]: Failed at checkpoint #3
22:51:11.201 [unclassified.MyOpenGLView]: Failed at checkpoint #4, activeColorMode is 0
22:51:11.201 [gameView.isOutputDisplayHDREnabled]: HDR display output requested - checking availability: NO

[another_commander]

It looks like the two display device enumeration methods we rely upon to extract the required information for HDR support do not refer to the same monitor. The first method (DisplayConfig API which gives us the monitorDevicePath) ends up referring to the MSI monitor, while the second one (EnumDisplayDevices which determines also whether the monitor is primary or not) ends up referring to the Acer.

Because the HDR capabilities querying structures are based on the DisplayConfig API method, we end up getting the properties of the MSI for our checkpoonts #3 and #4 (activeColorMode 0 means SDR), while at the same time we mark it as primary, becasue this specidc info comes from the EnumDisplayDevices method. What should happen though is that we get the same monitor from both methods. Apparently the enumeration order is not guaranteed between different methods.

At this point I am left wondering why it worked the first time, though. At that moment both methods returned results referring to the same monitor, namely the ACER. So what happened then? MAbe restarting the system changed the device enumerations?

Can you try reversing the monitors so that the Acer becomes monitor #1 (and remains primary) and the MSI beomes monitor #2? Does it launch without the warning then? This could involve unplugging the MSI so that Acer is promoted to #1 and plugging it back in. But I think the check method should be made more robust, I had not thought that enumeration order could be arbitrary.

[phkb]

Want to know something really, really funny?

So, I swapped the cables on my monitors, making the HDR compatible Acer both my primary monitor AND monitor #1, and relegating my MSI monitor to second place. And here's what happened:

Code: Select all

08:33:33.754 [unclassified.MyOpenGLView]: Failed at checkpoint #1. monitorDevicePath: \\?\DISPLAY#MSI4BA9#5&1a66a0b3&0&UID4353#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}, wcsDeviceID: \\?\DISPLAY#ACR0BAC#5&1a66a0b3&0&UID4354#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
08:33:33.754 [unclassified.MyOpenGLView]: Failed at checkpoint #3
08:33:33.754 [unclassified.MyOpenGLView]: Failed at checkpoint #4, activeColorMode is 0
08:33:33.754 [gameView.isOutputDisplayHDREnabled]: HDR display output requested - checking availability: NO

Yep, failed again. See, that's really funny. Really, really funny. ha ha ha ha ha ha ha hah ah ahahsdh a..

I love technology.

[another_commander]

Just to keep everyone up to speed, with some continuation of the discussion on Discord while the forum was out, it looks like we now have a solution to the problem. Standing by for a bit more testing before merging the branch containing the fix.

[phkb]

OK, testing complete. After swapping the monitors around again, Oolite was still able to detect the primary monitor had HDR and enabled it without any fuss. Success!

[phkb]

And the funnies just keeps on coming. So, I reverted to the original trunk build, as I anticipate I'll be building a new one shortly. And I started the game in HDR, and guess what? No issues. Straight in, no complaints.

Not sure whether it was the act of moving the cables (which I did while the system was running), or something else that changed the registry somehow. But it works.

Grr.

[another_commander]

It just seems that Windows enumerates devices arbitrarily whenever it restarts or the monitor topology changes. So now we use a more robust detection which should work regardless of device ordering.