not everyone plays every bit of content in every game, local compilation still happens pretty regularly.
Yes. Which is why I emphasized that this mostly comes into play on the first boot of a game and would go away VERY rapidly if you ran multiple collections.
It is not limited to the first launch but it is most noticeable on it.
The shared precompiled shaders are a great solution for a bunch of stuttering, and they are only available on Linux because they actually require the compatibility layers.
Funny enough, MS have been talking about (and implementing?) that for their xbox store games or whatever. Which is actually a REALLY good approach if you ask me.
The fact is: from the data we have so far, it looks like Bazzite is a better experience on a handheld Microsoft co-developed when compared to Windows.
No, we don’t. Which is my point.
Again, I would love to see a rigorous methodology that argues this (and if I am not familiar with Cyber Dopamine’s game, please, someone link me to their methodology). But I have a scientific background: I can cherry pick whatever you pay me to cherry pick.
And, quite honestly? If the performance is mostly noise outside of that first boot after a major patch? That might be awesome if I am paying 80 bucks to play a 4 hour CoD campaign once. That is less than meaningless if I am looking at something like Crusader Kings 3 where I will log hundreds of hours before the next one.
Which gets back to… what is the point of looking at benchmarks? Is it to feel happy that your team won? Okay. You do you. Or is it to make informed decisions.
And as someone who would really prefer Linux (Proton or otherwise) to be a first class citizen? Actively misleading people is just going to hurt in even the medium run.
… Also, Wine is not an emulator, but I think you know that. ;)
My inner pedant thinks that it is worth actually looking at the definition of an emulator rather than the title of software. But mostly it is just a good way to weed out the people who were never going to engage in a good faith discussion :)
the wine part, its more or less based on the end goal of the software. traditional game emulation is software that is used to try to mimic the hardware in question. Wine focuses on trying to be windows, rather than the physical PC hardware itself, so the type of thing youre trying to emulate is fundamentally different.
emulation in general is functionally a compatibility layer. Wine exists on the highest level of compatibility layer because its not trying to rewrite what the hardware is necessary doing (as both the hardware is the same)
Wine is the same level as Teknoparrot is (teknoparrot is compatibility layer for arcade maches that use X86 based pcs for hardware), vs MAME, which emulates non x86 based arcade machines.
it gets mega pendantic because of how closely emulation and compatibility layers are intertwined, but they arent two overlapping circles. a compatibility can use emulation but doesn’t require it.
I just like defining the difference between the two simply by the goal. emulation targets machine to then get to software, where compatibility layers target the software directly. and will target hardware only when necessary.
Yes. Which is why I emphasized that this mostly comes into play on the first boot of a game and would go away VERY rapidly if you ran multiple collections.
It is not limited to the first launch but it is most noticeable on it.
Funny enough, MS have been talking about (and implementing?) that for their xbox store games or whatever. Which is actually a REALLY good approach if you ask me.
No, we don’t. Which is my point.
Again, I would love to see a rigorous methodology that argues this (and if I am not familiar with Cyber Dopamine’s game, please, someone link me to their methodology). But I have a scientific background: I can cherry pick whatever you pay me to cherry pick.
And, quite honestly? If the performance is mostly noise outside of that first boot after a major patch? That might be awesome if I am paying 80 bucks to play a 4 hour CoD campaign once. That is less than meaningless if I am looking at something like Crusader Kings 3 where I will log hundreds of hours before the next one.
Which gets back to… what is the point of looking at benchmarks? Is it to feel happy that your team won? Okay. You do you. Or is it to make informed decisions.
And as someone who would really prefer Linux (Proton or otherwise) to be a first class citizen? Actively misleading people is just going to hurt in even the medium run.
My inner pedant thinks that it is worth actually looking at the definition of an emulator rather than the title of software. But mostly it is just a good way to weed out the people who were never going to engage in a good faith discussion :)
the wine part, its more or less based on the end goal of the software. traditional game emulation is software that is used to try to mimic the hardware in question. Wine focuses on trying to be windows, rather than the physical PC hardware itself, so the type of thing youre trying to emulate is fundamentally different.
emulation in general is functionally a compatibility layer. Wine exists on the highest level of compatibility layer because its not trying to rewrite what the hardware is necessary doing (as both the hardware is the same)
Wine is the same level as Teknoparrot is (teknoparrot is compatibility layer for arcade maches that use X86 based pcs for hardware), vs MAME, which emulates non x86 based arcade machines.
it gets mega pendantic because of how closely emulation and compatibility layers are intertwined, but they arent two overlapping circles. a compatibility can use emulation but doesn’t require it.
I just like defining the difference between the two simply by the goal. emulation targets machine to then get to software, where compatibility layers target the software directly. and will target hardware only when necessary.