Forza Horizon 5 on Linux? Yeah okay fine, Proton Experimental was updated

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

Or is there now a line in proton something like:
if
Age of Empires 4 do these things,
else if
Forza Horizon 5 do these other things

Why are game specific fixes or hacks needed so often?

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

Or is there now a line in proton something like:
if
Age of Empires 4 do these things,
else if
Forza Horizon 5 do these other things

Why are game specific fixes or hacks needed so often?

A lot of it is because Wine, DXVK and VKD3D-Proton are incomplete and chasing often moving targets. It's a matter of completing API support for Direct 3D, Windows APIs and so on. In some cases, there are specific fixes for certain games, like forcing your GPU to be shown as a specific vendor and stuff like this.

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

It's mostly incomplete or unimplemented functions and libraries with a few hacks mixed in.

You can grep the changelog for FH5 to see what was needed:
https://github.com/ValveSoftware/wine/commits/experimental_6.3

Some of it will probably be merged in upstream Wine, some will not.

Did someone try this yet and can actually comfirm it works on plain "Proton Experimental"? I'm asking because https://github.com/ValveSoftware/Proton/issues/5285 is a huge mess with questionable workarounds and people throwing in all kind of non related and obsolete information in all over the place.

As the official ChangeLog is just saying it works I just want to ask if:

* Does it *really* work on NVIDIA?
* Does multiplayer work as well?

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

Or is there now a line in proton something like:
if
Age of Empires 4 do these things,
else if
Forza Horizon 5 do these other things

Why are game specific fixes or hacks needed so often?

This has me confused too. People say it's just an API that's not fully implemented, but what are really the odds of this particular game using a part of a given API that NONE of the other hundreds of games, massive complex AAA included, has not used?
It just doesn't make sense to me. It doesn't add up.

what are really the odds of this particular game using a part of a given API that NONE of the other hundreds of games, massive complex AAA included, has not used?

Pretty big.

Try grepping the Wine sources for things like "stub", "unimplemented" and "FIXME".

Edited to add:

There might even be a bigger chance of this happening with big AAA releases. There's a bit of a mono-culture in gaming these days. Most games will use an existing engine like Unity or Unreal. This is good for Wine since adding support for one such game usually means many others will be supported inadvertently.

An AAA title might mean a totally new engine, or something very customized. It might very well use other, previously untested parts of an API or use it differently and trip up Wine.


Last edited by whizse on 12 November 2021 at 3:58 pm UTC

* Does it *really* work on NVIDIA?
* Does multiplayer work as well?

The issues reported there for nvidia look very similar to the same issues that still exist today in Forza Horizon 4. With that game it did a weird thing for me where it crashed a lot when I started, but then gradually got less crashy. Maybe related to shader compiling?

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

Or is there now a line in proton something like:
if
Age of Empires 4 do these things,
else if
Forza Horizon 5 do these other things

Why are game specific fixes or hacks needed so often?

In the case of Age of Empires IV at least, none of the changes needed were game specific hacks. Only three changes were needed to get the game to work, and all of them were general fixes which could apply to other games:

First, a missing function needed to be added, or the game wouldn't start up:
https://source.winehq.org/git/wine.git/commit/06104aec963f827ddd4f9d41d1ae72983779859f

Then, all of the buildings and units were invisible due to a bug in how things were arranged in video memory:
https://github.com/HansKristian-Work/vkd3d-proton/commit/2a8b5471cadd379720cf383377bc78c44b78e7b9

Finally, a crash would occur as the game used some invalid printf() format specifiers, which windows would ignore, but wine previously didn't:
https://source.winehq.org/git/wine.git/commit/0c6bab9339d62c8952692911f055ccbc95d956f6

I'm guessing most of you already knows this, but here's a simplified turn of events for Proton/Wine development that's hopefully not altogether incorrect:

The story of Game.exe

Game.exe is released but crashes on start in Wine. It requires Foo() and Bar() library.dll. Foo and Bar are implemented by someone reading the API documentation from Microsoft. Bar isn't really used by the game so a minimal version is added to fulfil the dependency for the game. The game works.

The sequel Game2.exe is released but crashes on start because it needs the full implementation of Bar. Bar is implemented in Wine, the game works.

An update to Game2.exe is released and crashes on start in Wine. Turns out that Game2.exe now calls Bar with NULL instead of the expected integer value. This is undocumented behaviour but works on Windows, so the behaviour in Wine is changed to match Windows. The game works again.

Game3.exe for Windows 11 is released. It crashes on start in Wine. It requires library2.dll to run. Someone figures out that if the game runs on Windows 10 the older library.dll is used instead, a game specific hack that reports version 10 for Game3.exe is added and the game works.

Now multiply this for all the dlls and functions a game need to run and things get complex fast.

(The movie rights to this original short story have already been acquired by Sony Pictures Entertainment™)


Last edited by whizse on 12 November 2021 at 2:33 pm UTC

This is great news, because I was recently thinking that the game looked pretty sweet. Too bad I have an older GPU and would be sad to play on low settings.

It would be nice if one day Steam allowed you to addon other store API's like how Lutris works. They could then make it so dependencies install correctly and also fix all the issues with add non-steam game.

Allot of people add their non-steam games to steam in order to run via proton but often it won't work because steam doesn't install any requirements to even get the game running.

Also proton/dxvk is still not 100% launcher friendly. For example there are issues with Tarkov BSG launcher and PlanetSide2, the former appears to need some dotnet foolery which should be solved by Mono but isn't...

ONE DAY!

I often see this sort of thing and wonder: are these general fixes to proton that have been missed?

Or is there now a line in proton something like:
if
Age of Empires 4 do these things,
else if
Forza Horizon 5 do these other things

Why are game specific fixes or hacks needed so often?

This has me confused too. People say it's just an API that's not fully implemented, but what are really the odds of this particular game using a part of a given API that NONE of the other hundreds of games, massive complex AAA included, has not used?
It just doesn't make sense to me. It doesn't add up.

As a developer who has worked with the Windows API before I can tell you it is very large.

Outside of the Windows API anyone can create their own DLL(this is just a shared library).

For instance, rust DLLs for Windows have been causing problems for Wine recently as that is a newer Language with its own DLLs.

Then you have different version of Windows with different APIs and this all adds up to a constant moving target of things to implement.

I personally don't like the idea of Steam attempting to install additional software. That's what a package manager is for - and if Steam ever attempts to override it, I'll burn it out of my system if I have to. Or am I missing something outside of that? I don't use Lutris, and I'm assuming the dependencies are installable packages rather than grab-another-flatpak type setup.

I think he is talking about windows dependencies that the game has. Using protontricks in case. Lutris use their own scripts.
Not linux libraries, windows packages like vcrun, dotnet, etc.

Try grepping the Wine sources for things like "stub", "unimplemented" and "FIXME".

Oh I totally believe there's a *lot* of areas where Wine is lagging behind. It goes without saying, really.

But what are computer games?
It's a program that takes user input, writes a shitload of data to the screen and often utilise the network interface. What goes on from one game to another should in principle be pretty much the same, as far as the system libraries goes? Architecturally the programs should share far more than they diverge from each other. As far as I can understand...!

So what on earth could it be that this game used from a system library that all the other games don't?

I mean, I'm not sitting here claiming or pretending to know or understand more than what I do, I am merely asking based on my very limited experience with software development. It's not like we talk about some exotic hardware peripherals here. And it's hard to understand why it should utilise some fringe windows functionality no others do.

*shrugs*


Last edited by Beamboom on 12 November 2021 at 5:52 pm UTC

I'm guessing most of you already knows this, but here's a simplified turn of events for Proton/Wine development that's hopefully not altogether incorrect:

The story of Game.exe

Game.exe is released but crashes on start in Wine. It requires Foo() and Bar() library.dll. Foo and Bar are implemented by someone reading the API documentation from Microsoft. Bar isn't really used by the game so a minimal version is added to fulfil the dependency for the game. The game works.

The sequel Game2.exe is released but crashes on start because it needs the full implementation of Bar. Bar is implemented in Wine, the game works.

An update to Game2.exe is released and crashes on start in Wine. Turns out that Game2.exe now calls Bar with NULL instead of the expected integer value. This is undocumented behaviour but works on Windows, so the behaviour in Wine is changed to match Windows. The game works again.

Game3.exe for Windows 11 is released. It crashes on start in Wine. It requires library2.dll to run. Someone figures out that if the game runs on Windows 10 the older library.dll is used instead, a game specific hack that reports version 10 for Game3.exe is added and the game works.

Now multiply this for all the dlls and functions a game need to run and things get complex fast.

(The movie rights to this original short story have already been acquired by Sony Pictures Entertainment™)

This account underlines for me a major difficulty for Wine: Windows stuff tends to need not just Windows, but stacks of proprietary third-party libraries, which Wine also needs to duplicate.

It's a program that takes user input, writes a shitload of data to the screen and often utilise the network interface. What goes on from one game to another should in principle be pretty much the same, as far as the system libraries goes? Architecturally the programs should share far more than they diverge from each other. As far as I can understand...!

So what on earth could it be that this game used from a system library that all the other games don't?

So, from a skim of the changes in git, one of the things Forza 5 needed was Performance Counters. These we're technically not required, but the stubs for the functions was changed to return true instead of false to make the game happy.

I have no idea if the game uses those for error diagnostics, or to adjust performance settings during runtime so the game is actually missing some feature?
https://github.com/ValveSoftware/wine/commit/ed0d3339339b397b305ef218c6dcec46f789101e

Another thing was speech synthesizer support. Again, not fully implemented but stubbed in Wine, and again, no idea if that's something the game actually uses. GPS directions maybe?
https://github.com/ValveSoftware/wine/commit/822c137a52117c03f205ad6b0af71d765983f724

🎵🎵 The APIs themselves keeps on expanding and expanding
In all of the directions they can whizz
As fast as it can be implemented, at the speed of light, I read
Twelve million lines a minute, and that's the fastest speed there is 🎵🎵
(Sorry MP


Last edited by whizse on 12 November 2021 at 9:16 pm UTC

This account underlines for me a major difficulty for Wine: Windows stuff tends to need not just Windows, but stacks of proprietary third-party libraries, which Wine also needs to duplicate.

Surely any third-party library will be distributed with the game and not assumed already installed on the given system? It's the underlying layer that is handled by Wine? But it do need to provide the APIs used by those too, of course.


Last edited by Beamboom on 15 November 2021 at 8:26 am UTC