protonscr

Resident Evil 3: Nemesis

protonopen appid 1999Game compatibility - Unofficial
ValveSoftware/Proton#8238 · opened 2024-11-12 by ShadowOne333 · updated 2025-03-19 · 4 comments · github · game page · search this game
1 matching comments, n / p to jump
SShadowOne333 2024-11-12 github

Compatibility Report

  • Name of the game with compatibility issues: Resident Evil 3: Nemesis (1999)
  • Steam AppID of the game: Non-Steam game

System Information

The following are all Steam Deck specs, but the issue can be reproduced in any Linux distro with Wine/Proton installed.

  • GPU: 8 RDNA 2 CUs, 1.0-1.6GHz (up to 1.6 TFlops FP32)
  • Video driver version: Mesa 24.2.5
  • Kernel version: 6.5.0-valve22-1-neptune-65-g9a338ed8a75e
  • Link to full system information report as Gist:
  • Proton version: Tried Proton 7.0-6, 8.0-5, 9.0-3, Experimental and even Proton GE 9.16 and Wine 9.0 & 9.2, all present the same issue.

I confirm:

  • [X ] that I haven't found an existing compatibility report for this game.
  • [X ] that I have checked whether there are updates for my system available.

I've been trying to get RE3 (1999) from GOG working on Linux/Steam Deck with the HD or Seamless HD Project (SHDP) mod for over two months now, but no matter what I try, I always end up with the same result, which is the actual backgrounds/textures looking really small on the upper-left corner of the screen, as seen in these images:

https://imgur.com/a/Bj8o51s

To get the game running on Steam Deck / SteamOS with Proton (or any other Linux distro with Wine or Proton), I use the following DLL overrides:
WINEDLLOVERRIDES="d3d9,d3dcompiler_47,ddraw,dinput8,dsound,libwebp,xaudio2_9"=n,b

Those same overrides are the ones I use for RE2 (1998) and it works perfectly with Classic Rebirth alongside the Seamless HD Project mod. RE1 CR+SHDP does work too (although that one required some dgVoodoo2 intervention). While RE3 does work with Classic Rebirth on its own, it's the HD mod causes that graphical issue on Steam Deck (and can be reproduced in any other Linux distro too).

I tried screwing around with the DLLs, and found that dinpu8 is the one that seems to load the HD textures.
According to some tests by several other people from both the Proton GE Discord and the Seamless HD Project Discord, it's possible that the issue could be related to the implementation of DirectX made by Wine/Proton (WineD3D).

Reproduction

Resident Evil 3: Nemesis (1999) from GOG

  • It's important to note that the version of RE3 needed for the mods to work is the Japanese version.

To run the game with the exact same conditions to reproduce the HD textures/backgrounds glitch, the following is required:

Once the game is properly installed with the Japanese language, all that's needed is:

  • Replace the original EXE with the one from the Official 1.1.0 SourceNext patch
  • Replace the ddraw.dll from the original game with the one from the Classic Rebirth mod
  • Copy all contents from the RE3 HD mod into the same place as the EXE. Warning: If the HD mod has a ddraw.dll file, do NOT replace the one from the Classic Rebirth mod!
  • To make the game run under Linux/Steam Deck, the following DLL overrides are required:
    WINEDLLOVERRIDES="ddraw,dinput8"=n,b
    Those are the bare minimum of DLL needed to get the HD mod running. Afterwards, running the Wine DLL Override command alongside wine "BIOHAZARD(R) 3 PC.exe" should make the game run with the following window opening, and then the game window with the graphical glitch:
    Screenshot from 2024-11-06 12-21-47
    Screenshot from 2024-11-06 12-22-00
Kkeenanweaver 2024-11-14 github

Linking back to issue originally opened at DXVK repo: https://github.com/doitsujin/dxvk/issues/4431

WineHQ bug report: https://bugs.winehq.org/show_bug.cgi?id=53775

SShadowOne333 2024-11-15 github

Here's the WineHQ bug report I made a few days ago too for reference:
https://bugs.winehq.org/show_bug.cgi?id=57395

Sadly there's no indication on what could be happening for this particular instance, but from my and others' tests, I'm inclined to believe it could be something related to WineD3D.

SShadowOne333 2025-03-10 github

Upon further investigation, it seems that the most plausible culprit for this specific issue is related to a polygon offset scaling with WineD3D:
0024:err:d3d:wined3d_adapter_find_polyoffset_scale PolygonOffset scale factor detection failed, using fallback value 2^23.

That is the exact output I get from the log, and it seems to be the only repeating error when running the game with the HD texture pack. Everything else is just warnings that don't affect gameplay.

Here's the game's log when running it through Wine 9.0 (applies for the recent Wine 10 as well):
game.log

SShadowOne333 2025-03-19 github

User @dariox86 was able to find a workaround for this issue in this issue report here:
https://github.com/doitsujin/dxvk/issues/4431#issuecomment-2727071152

He basically patched the ASI file so it works properly with DXVK. I tested it through Heroic Launcher and the game with the patched ASI works properly with Proton 9.0 Beta or Proton GE. It could possibly work just fine if added as a non-Steam game if the user desires.

However, the main issue with WineD3D still persists to get the original ASI file working, and from Dario's debugging efforts, it seems that Wine/WineD3D is somehow bypassing a subroutine from the ASI that is supposed to give the proper vertical resolution of 960 into the game:
https://bugs.winehq.org/show_bug.cgi?id=53775#c7

Subroutine at 0x10004430 in bio3hd.asi is successfully injected in ddraw.ddl and executed. This brief subroutine stores a couple of words in memory representing the intended resolution of 1280x960. This behavior is consistent between Windows and Wine. An issue however is apparent when the next injected subroutine at 0x10004460 in bio3hd.asi is called.
On Windows this subroutine takes a resolution of 1280x960 and few other values as input parameters. While on Windows these parameters are correctly passed, on Wine the vertical resolution of 960 is not passed to the subroutine, leading to an unexpected condition.
This is the earliest occurrence of misbehavior on the part of Wine that I managed to come across. I don't know whether the problem lies in between the two calls or earlier in the execution of the program.

This is what ESP register looks like when entering subroutine 0x10004460 in bio3hd.asi under Windows:
[esp+4] 0x0A761040
[esp+8] 0x00000500   <- 1280
[esp+C] 0x000003C0   <- 960
[esp+10] 0x00000140  <- 320
[esp+14] 0x0A88D040

This is what it looks like in Wine:
[esp+4] 0x00000000
[esp+8] 0x028ADAC0
[esp+C] 0x00000500   <- 1280
[esp+10] 0x00000140  <- 320
[esp+14] 0x055BD000

Under Wine, the value representing the vertical resolution is missing from the stack.