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
```
