I wish we could use the Linux binary instead of running it through proton.

Well, technically, you could also use the newer BFG edition that combines both of the campaigns into a single package, and that definitely requires Proton, because it was never ported from Windows.

Whilst it's nice to see this working through Wine/Proton; I'd imagine most people will be better off compiling:

• RBDoom-3-BFG: https://github.com/RobertBeckebans/RBDOOM-3-BFG (for BFG edition)
• dhewm3: https://github.com/dhewm/dhewm3 (for vanilla doom3)

There seems to be packages available in the repos for Ubuntu, Arch, etc.
Perhaps Valve could find a seamless way to integrate projects like these into Steam somehow.
Something better than the "add a non-steam game" route - a workshop mod?

@andrew-mcmahon RBDoom-3-BFG is unstable and misses some important features like achievements and online multiplayer. dhewm3 is also unstable, contains bugs not presented in vanilla and incompatible with most existing mods. Unless these two projects find workaround and can deal with publishers (in which I doubt), I wouldn't want them to appear on Steam.

Found glitches:
Glass windows are fully opaque:



Glass + messed up UI image:

@xDShot Post your system info in a gist, please.

I'm attaching (resized, I forgot that this game is hardcoded to 4:3 aspect) screen shots to show things work on my system.

System:
https://gist.github.com/kode54/3ff952f39b407d6f806a6779838f5335

Using the RX480 listed there.

https://gist.github.com/xDShot/072b363fb24811836d146ce3242887ab

dhewm3 is also unstable, contains bugs not presented in vanilla

Is it? Could you file bugreports for those bugs and instabilities at https://github.com/dhewm/dhewm3/issues ?

I don't suffer those graphical glitches either so it must be specific to Intel integrated gfx.
Steam system info
I would've thought that online multiplayer is completely dead anyway? (at least according to steamDB)

What I will say is that enabling HDR in RBDoom3-BFG seems to be the cause of some rendering issues.
Drop down a console (¬) and turn that off with r_useHDR 0
Soft shadows are also very demanding; the basic stencil shadows are OK.

No real issues with dhewm3 either.
I've noticed the older engine stutters a bit in places and the GUI + videos are 4:3 as they were originally.
Even if the GUI can't be fixed easily; non-stretched/letterboxed videos would be a nice addition.

RBDoom3-BFG screenshots with GALLIUM HUD @ 1080p

dhewm3 screenshots with GALLIUM HUD @ 1080p

A few more comparison pics here and here.
Personally I love having the choice of which edition of Doom 3 to use.

@kisak-valve Requesting an XAudio2 label for this game...

Doom3 from 2004 uses XAudio2? (Very unlikely, unless they updated the soundcode for the Steam release)
Or did you mean Doom3 BFG, which is discussed at https://github.com/ValveSoftware/Proton/issues/569 ?

Oh, shoot, i clicked the wrong one. Dan is right, I meant the other one, original Doom3 uses OpenAL!

@andrew-mcmahon even if there exist some modern port, this games should simply work with Proton, like the others WIndows games on Linux, that the subject here. Advanced users could always try others ports. I just tested Doom3 with Proton 3.16-3 and it works very well. You click, you play! @kisak-valve It could be whitelisted.
https://gist.github.com/legluondunet/0f0a56fb4e9cb743f111385e554fce69

It doesn't launch at all on Intel 7700K with just Intel HD graphics.

Game is working fine now (Proton 3.16-6 Beta).

Doom 3: BFG Edition does not start with Proton 4.2-2. Works correctly with 3.16-8 Beta. Can you verify if it also affects you?

@kisak-valve Sure, log attached:
steam-208200.zip

@kmaterka Here’s a shot in the dark: Try removing OpenVR?

@kode54 Good shot! After removing these two:
./steamapps/compatdata/208200/pfx/drive_c/windows/syswow64/openvr_api_dxvk.dll
./steamapps/compatdata/208200/pfx/drive_c/windows/system32/openvr_api_dxvk.dll
game started.

Although, specifically, it appears it was the input code crashing somewhere related to libfreespace, but that only appears to get loaded if the OpenVR framework is present. It would be beneficial to those attempting to run the VR integration on Linux to fix this, but until then, it would also be nice if the game’s current VR libraries didn’t crash in Wine even without OpenVR installed in Steam, unless those libraries came extra because of something you did.

Yes! It is this exact issue, as far as I can remember it does it on stock 9.0-4, let me double check and get back to you (will edit this comment).

EDIT: it looks like stock 9.0-4 doesn't have this issue, but an other one! the camera movements are a bit juddery, but when you only strafe and don't move the camera it's fine. So the issues starts with 9.0-4 but not the one I initially described!

I'm playing with the original engine, and I've been trying with the engine's config variable "m_smooth=1" and "m_smooth=0" but no difference.

@Deus-nsf Thank you for the confirmation! I took another look and I'm not noticing any difference between 8.0 and 9.0 ... I saw you mention multiple times that you are using the original engine ... is this an option I need to toggle somewhere? I'm just launching the game and using the default options - the appid is 9050, so I believe we are testing the same version of the game in general. Separately, the 9 -> 10 issue is still definitely a regression that I'll look into deeper :)

@Deus-nsf Also - could you please try the experimental "bleeding-edge" branch? You will need to manually select "bleeding-edge" as the beta option for Proton - Experimental. A different regression was just fixed this week, and the behavior seems better to me with bleeding-edge than default experimental. Are you seeing an improvement as well? Is it still worse than 9?

Thanks a lot for taking a look at this again, when I mention "original engine", it just means that it's the vanilla default engine that ships with the Steam release, I mentionned it because there's several quality source ports for Doom 3, but I'm using none of them for the deck, just the regular .ini tweaks to put the game in 16/9, that sort of stuff :)

I'll try the bleeding edge version right now and get back to you with an edit again :)

EDIT: indeed, that seems to be completely fixed in bleeding edge! Great to see!
The game still has some weird micro stutter issues but I don't think it's Proton's fault, a few months back there were some updates to the way frame limiting / refresh rate handles in Gamescope/SteamOS and I notice many games being affected by that (HL2 is an example too saldy), but this is an entirely other issue, as far as Proton goes, this looks like it's fixed, thank you so much!

If you feel like having the courage, you need to enter com_fixedtic 1 in the console or com_fixedtic=1 in the .ini, and then lock the gamecope limiter to 62 Hz to achieve 62 FPS, this will make the game depend on refresh rate speed, but since the original game was meant to run at 62.5 FPS, it's extremely close to the intended game speed :) It's a bit obscure to do this, but this way the game is very smooth and at (almost) intended speed, well, it was very smooth for the longest time until some updates dropped and maybe changed things idk.

@Deus-nsf Thank you for the feedback and the testing!! I don't play this game regularly, so it is great to know that it seems completely fixed. We might iterate on this fix a bit more as it was actually fixing a regression with a different game which still isn't 100% fixed ... if so, I'll let you know. If you notice any "weirdness" with the mouse control in bleeding-edge after playing more, please let me know :)

For science I updated the Proton Exp build which is still configured with the bleeding edge branch, and the fix seems to hold so far :)
Now I have to really do something about that micro stutter issue (not doom 3 related), since I don't know what SteamOS version, it affects the compositor, no matter the refreshrate you choose, there's occasional, very visible stuttering, it's on every game I tried so far. Wasn't like this months ago (and for years before that change), I really owe myself to create an issue maybe on Gamescope's GitHub. It would be useful to enable tearing to see if it's a sync issue, but that feature has been broken for 2+ years at this point...
TLDR: Proton good, Gamescope/Game Mode eeeeh, not so much, at least I'd say it is the limiting factor on the Deck so far, at least in non VRR scenarios. (or maybe it's related to how input works... really hard to nail down this issue)

There was a major push that was made on the stable SteamOS branch recently, and I saw many occurences in the changelog mentionning the compositor and frame delivery, and how it would apparently fix things mostly for VRR.
I'm not sure what changes were made under the hood, but it seems to have completely fixed the presentation pacing issues the Deck had for a while (9 months+!) now! Now every game that can maintain the target refreshrate have perfect presentation and it's amazing, I'm so happy!

Now we only need the ability to restore the "allow tearing" functionality for latency enthusiasts!