HDR in Control (a patch released by a developer post-launch, not
actually in the game sadly) tries to set a video mode with
DXGI_FORMAT_R16G16B16A16_FLOAT.
This seemingly works on Windows, and based on FindClosestMode etc
documentaton, this seems required to work for any format that scanout
it supported for.
It's really not like the bpp is meaningful on Windows with the
distinction of 8bit and 10bit not working in GDI modes at all.
Nor does it end up actually setting anything on Linux/Deck where
modesets are emulated.
So, treat DXGI_FORMAT_R16G16B16A16_FLOAT as 32bpp so the
FindClosestMatchingMode and EnterFullscreenMode calls succeed.
Game seems to be doing something horrible on its own, literally impossible
to make it run smoothly. This at least seems to limit excursions to ±10ms
and fix the camera flinging back and forth when running the game through
Gamescope.
This game (or nw.js) comes with a hard-coded frame rate limit that
behaves more like a random number generator which happens to average
out at around 16ms on a good day.
Fix this complete mess by enabling ours on top of that.
This reverts commit 79f6239df3.
Some engines use SEQUENTIAL presentation despite not making use of it, and
sparse binding is much slower than expected on Nvidia drivers, which leads
to massive performance regressions across the board.
For two reasons:
1) Some apps will only enable or attempt to enable HDR if BitsPerColor is >= 10.
2) Encouraging apps to create 10-bit swapchains for use in hardware dithering on Gamescope/Steam Deck and to have more precision thru scanout color transforms
This way, memory regions bound to consecutive pages are more likely
to end up in consecutive memory regions, which allows batching page
table updates more efficiently.
Player movement and animation can bug out at high fps like issues moving around objects and the players head detaching slightly when moving backwards.
Seems like it also helps some crash issues.
NVAPI is disabled now due to crashing issues in a wine-specific code
path within the game, but we still want it to detect the correct GPU
so that it doesn't complain about drivers and also allows users to
enable Raytracing.
Disable stdcall aliasing and enable kill-at to ensure our exported
functions don't have the @8, @40, etc suffixes.
This still keeps `--enable-stdcall-fixup` as otherwise the linker can
get confused trying to find exports from the .def. This does not result
in aliases being added, just for them to be found to add to the export
table.
This also switches d3d11 to use the MinGW provided dxgi.lib for linking
and d3d10 to use the MinGW provided d3d11.lib for linking.
Unfortunately the .a's we output seem to still have the @blah that we
killed so we cannot use them for internal linkage since using kill-at.
Tested that what we get out of MinGW now is what we want with dllexp.
Supercedes: #3590
Exports
```
➜ build git:(master) ✗ winedump -j export src/dxgi/dxgi.dll
Contents of src/dxgi/dxgi.dll: 129505860 bytes
Name: DXGI.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2D Tue Aug 1 22:33:33 2023
Version: 0.00
Ordinal base: 9
# of functions: 9
# of Names: 5
Addresses of functions: 00423028
Addresses of name ordinals: 00423060
Addresses of names: 0042304C
Entry Pt Ordn Name
00007C17 9 CreateDXGIFactory
00007BF3 10 CreateDXGIFactory1
00007B62 11 CreateDXGIFactory2
00007C3B 16 DXGIDeclareAdapterRemovalSupport
00007CD8 17 DXGIGetDebugInterface1
Done dumping src/dxgi/dxgi.dll
```
```
➜ build git:(fix-stdcall-32-bit) winedump -j export src/d3d11/d3d11.dll
Contents of src/d3d11/d3d11.dll: 263021637 bytes
Name: D3D11.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2E Tue Aug 1 22:33:34 2023
Version: 0.00
Ordinal base: 18
# of functions: 7
# of Names: 4
Addresses of functions: 005E3028
Addresses of name ordinals: 005E3054
Addresses of names: 005E3044
Entry Pt Ordn Name
00020045 18 D3D11CoreCreateDevice
000200AA 22 D3D11CreateDevice
0002010E 23 D3D11CreateDeviceAndSwapChain
0002025F 24 D3D11On12CreateDevice
Done dumping src/d3d11/d3d11.dll
```
Import of DXGI in D3D11
```
offset 005e1014 dxgi.dll
Hint/Name Table: 005E408C
TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970)
ForwarderChain: 00000000
First thunk RVA: 005E4300
Thunk Ordn Name
005e4300 4 CreateDXGIFactory1
```
Some apps such as level editors such as Hammer World Editor, some GUI apps/launchers etc use window overrides in presentation.
Previously we'd remake a new surface every time, which was incredibly slow making these apps basically unusable.
Now we keep one surface + swapchain + image views around per window/window override we have, along with the frame latency objs + frame counter.
(Obviously an app may present to multiple windows in a frame, so for frame latency purposes we track that per-window.
The game has 3 v-sync options but doesn't explain what they do.
0 = 60 FPS
1 = Monitor Refresh Rate
2 = 30 FPS
Framerate is capped at 60 in missions and then up to monitor refresh in the main menu and tavern area
This PR would provide a better default experience for people using option 1 with high refresh displays
This trips up Stalker Anomaly for some reason, but initializing an output
is not meaningful anyway in this situation since we either know the output
in question already, or we don't and it cannot be in a non-default state.
Closes#3531.
Philip Rebohle
Joshua Ashton
Blisto91
Paul Gofman
WinterSnowfall
Robin Kertels
Paul Gofman
Margen67
Tatsuyuki Ishi
Jens Peters
Etaash Mathamsetty
Georg Lehmann
pchome
Alpyne
Trevonn