Honestly not missing much lol. There’s like 1000 hours of good TV content in total out there IMHO.

It is a translation layer, but the bit you added “to native code” sounds like you’re misunderstanding what translation layer means.

Games use a collection of APIs (DirectX is a set of APIs, but there’s others to handle offer operations like network access and such) to interact with OS functionality, and also receive communicarion back from the OS (the windows message loop). Proton and wine are implementations of those APIs that translate the API calls to their equivalent in linux, as well as setting up their own message loop that translates messages from the linux kernel and UI system into their windows equivalent before sending them to the registered windows messaging loop functions.

A simple example would be if a function header in windows looks like int32 SomeFuncWin( int64 index, char* name ), but looks like int32 SomeFuncLinux( std::string name, int64 index ), then the translation would be something like:

int32 SomeFuncWin( int64 index, char* name ) {
std:string TranslatedName( name );
return SomeFuncLinux( TranslatedName, index );
}

So it doesn’t change/translate any of the code of the program itself, it just provides the environment that behaves exactly like a windows environment by translating the “hey could the OS do this for me?” requests from windows to linux. Note that not all translations are that simple, there might need to be more processing on the values, missing arguments might need to be filled in, irrelevant arguments ignored, sometimes data needs to be translated to another format, etc.

The speed ups can come from improved efficiency in the underlying implementations (which Vulkan has, as I understand even using a translation layer from DX to Vulkan in windows can result in better performance) or having fewer services running in the background.

I think most of the work is in the fact that there often isn’t an “equivalent call”, and it can be quite a lot of code to make it work. One funny thing is the whole esync-fsync-ntsync issue, where synchronization is done differently on Linux and on windows, and translating it was a big performance hit, and difficult to do accurately. If I understood correctly, esync, fsync and ntsync were a series of kernel patches implementing additional synchronization code in the kernel, with ntsync actually replicating the windows style.

Thanks for the additional infos!

Here is the protonfixes repo for reference: https://github.com/Open-Wine-Components/umu-protonfixes

Someone might want to ping that .ml user, since I’m instance banned from there, they won’t be able to see my answer

I was going off of protondb. I can’t vouch for each game on the list’s exact state on any given day, only that according to everyone who ranks on the website it’s native or gold.

Apex Legends worked on Linux every year except this one. League I’m told dropped support only recently (in the last couple of years). Like, idk man, there’s ups and downs to this data, but the point is not all competitive multiplayer games don’t work on Linux and seemingly the majority do based on steam and protondb data.

I guess the beefier your system is the less you will notice the impact of a greedy OS (because thats a fixed/absolute overhead) while the performance hit of having to translate directx through Proton will always be there (because that’s a percent-based overhead for each rendered frame)

So for the most top-end rigs, probably still Windows will squeeze a few more FPS. But it’s close.

At the end of the day Linux and Windows are both pretty comparable for gaming performance, so we shouldn’t worry about that as a deciding factor in which OS to choose, and can decide based on other merits.