I have noticed a very scary drift towards accepting wrapper based ports. Working as a developer and also a long term Linux user I can only believe that it is due to misunderstanding of the processes, restrictions, and licenses that go into porting a game.
It is not just about performance, there are many other factors that influence a “good” and a “bad” port. Also some ports can contribute to Linux in a more positive way than others.
I will give a quick explanation of the porting techniques and some of their advantages/disadvantages and then an explanation of my opinion on wrapped ports.
1. Native Engine.
The engine is already cross platform or ported during development and games are then exported to all platforms during the game development process, not after.
Games developers and artists usually do not have to do anything except export to the platform, QA test and report any bugs to the engine developers.
Platform specific bugs will be picked up by QA and fixed during the development process, usually with support from the original Engine developer such as Epic, Unity or Valve.
Bugs are fixed on all platforms at the same time and the engine can gradually be redesigned to be more cross platform and abstracted. Bugs found in one game will help the engine development and in turn can fix bugs in another game.
These engines are designed so that developers will either script in a language such as Javascript, C# or build to a specific cross platform API in C++. In most cases no platform specific code will be written by the developers.
For artists assets are designed to be easily exported to cross platform formats. Platform specific GUIs (Console/Desktop/Mobile) and settings/options may need to be created but this is easy to do with native builds.
One issue with native engine development can occur when the developer alters the engine source code themselves or by picking close source middleware or plugins that are not cross platform. This can usually be solved by building regularly for all platforms, picking cross platform middleware and trying to merge any upstream patches and changes in as soon as possible.
If for whatever reason they require a specific plugin which is not cross platform and no replacement can be found then the game may only be able to be released on one platform, this will be the same for all native porting techniques. As this occurs as part of the development process and not after it is simpler to fix with less risk to one specific platform.
Also with native engines there can still be performance issues, but as there is active support from the engine developer patches and changes can be made fairly easily and there is less stress and pressure on the developer to fix the issues themselves. A good example of this is OpenGL shader compiling. A well known issue with OpenGL is that shaders are compiled/optimized at first draw rather than when first created. This causes massive stutters especially with unique shader heavy engines. This means shaders ideally need to be pre-warmed. Separate shader objects does not entirely remove the performance penalty during first use but does speed up some compilation by removing the amount of shader program used and compiled. If an engine originally ships without this then there will be significant stutters on the Linux and Mac versions that do not appear on Windows. However as the native engine is always progressing is quite possible to cherry-pick the commits for SSO from the newer engine code. This shader issue is one of the reasons why Vulkan and SPRI-V will be very good for Linux, and without the support of Value and their development of Source 2 it may never have happened.
Even if a developer uses a pre built native engine but only builds for one platform and does not test or build for other platforms until after or near completion this would be classed in the “Native Port” section below. There are plenty of Unity developers which are falling into the trap of leaving their Linux and Mac exports until the last minute and finding they are having issues.
Examples: Unreal Engine 4, Unity, Source 2.
2. Native Port.
The game is ported after development (and possibly release) of one platform.
There can be issues with this is that there are certain engine techniques that do not translate well to all platforms. This can happen even with well abstracted engines that have not coded directly for one platform API (such as Win32).
Because the engine is not designed by the original developer and one platform is already finished development, it is difficult (but not impossible) to alter the engine to fit. There may also be certain middleware that is closed source and has not yet been ported to Linux. Support from the original engine developer may also have ended.
Along with the previously mentioned shader issue another difference can be in DirectX Constant Buffers have little penalty for mapping and updating them, but in OpenGL updating a Uniform Buffer every draw call can have a significant performance issues. An engine that is originally based around DirectX may not pre-warm shaders and significantly abuse per draw Constant Buffer updates. Redesigning the engine to support shader pre-warming and batching the constant buffers updates per frame or per object, may take a long time especially without support from the engine developer. It may also prevent the DirectX code from working properly and break the Windows build. This means Windows either needs to be fixed or the Linux code will diverge and need to be branched from the Windows code. Some of this can be elevated with the use of OpenGL 4 such as persistent mapped buffers and separate shader objects but there may still be worse performance compared to DirectX and this leaves out users of older GPUs or on the Mesa drivers.
The good thing is that whilst there are these issues, they can be fixed and the engine be updated over time, and new fixes for one engine can be back-ported or shared between developers.
As with native engines the game scripts and assets can be redesigned and optimised for the new platform creating platform specific GUIs. This may be more difficult if the art team has already left for a new project.
In most cases with a native port the developer either contracts out or ports in-house. The new code is usually owned by the developer and committed directly into their version control system. The developer is able to create new builds and fix bugs after the port has been complete. Patches are usually in sync with all platforms.
3. Native translation/abstraction layers and drop in replacement middleware.
Porters have access to the game source and the game is compiled natively but the original game code is largely untouched except for certain compilation fixes an bug fixes.
The game is then compiled against translation layers which are essentially native reimplementations of Win32 and/or DirectX or a console API. These layers are usually created by reverse engineering, lots of documentation/api reading, guesswork and many workarounds.
This has the same issues as true native ports in that certain DirectX features may not map well to OpenGL, except for the fact that it is now much more difficult to alter the original game code.
Redesigning the engine is definitely out of question and to fix the issues conditional compilation or certain work arounds might need to be used, which is harder to maintain than a well abstracted engine.
If the port is done by a third party they may have certain licensing agreements. This can be based on the porting company paying the original developer for the rights to distribute their game and they either get all or a percentage of profits for the ported platforms. So it is not possible for a developer to fix bugs on the platform or contract out the bug fix to a new developer they have to always go through the third party porter. One of the major disadvantages of this can be that patches become out-of sync with the original platform. e.g. The Linux DLC coming 6 months after the Windows DLC.
If for whatever reason the license agreement between the original developer and porter end, then the game has to be re-ported because the original developer has no access to the abstraction layer or middleware code.
A good example of the issue with this can be X3: Reunion from Linux Games Publishing. There are two versions of X3: Reunion, one that was done by LGP and then one that was re-ported internally.
Examples: Winelib, LGP.
4. Compatibility Layers.
The system translates the api calls as it is running and maps them to native implementations. The CPU architecture usually needs to be the same.
The porter has no access to the source code for the game and uses exactly the same binary and build as the original platform.
These are similar to translation layers in that they are reverse engineered and/or API reimplementations.
The advantage here is that along as the compatibly layer fully respects the original platforms API then any and all applications will be able to run very quickly with no cost.
The disadvantages can be performance issues and also issues if the original platform has some functionality that the new platform does not have. There can be the same issues as the native ports except now it is largely impossible to redesign the engine because there is no access to the code. Because of this a properly optimised native port or engine will always run better than a compatibility layer.
In most cases compatibility layers are meant to allow the user to run any software themselves and not meant for a third party porter to distribute an application. But it works for porting and distributing of some games where the code may be “lost” such as System Shock 2 as there is no other way.
Another advantage here for WINE is that it is open source so any changes and fixes help all Linux gamers. The good point about Crossover is that it is essentially a supported and stable version of WINE, so any money goes towards WINE development.
Examples: Crossover, Cedega and WINE.
5. Emulators.
A complete system is emulated with a separate OS or ROM running onto of the native OS. The CPU architecture can be completely different.
The advantage of this is it allows you to run games that were not developed for the current CPU architecture. Old consoles, 16 bit DOS games.
The disadvantage here is performance, even with a hardware virtualisation everything has to be translated and the port can never be optimised. This is why it is only really useful for low graphics applications or much older applications.
Examples: QEMU, Virtual Box, DOSBox.
7. Wrappers.
A compatibility layer is prebuilt and the original binary is wrapped in some way to allow executing as a native binary.
This could also include shipping a prebuilt version of WINE and having a script to load the executable.
The advantage is the same as compatibility layers and that the port is quicker release and patches may be in sync with the original platform. The added benefit is that the developer or porter has control over the specific compatibility layer version or technology that the user will use so can pick one that has the least issues.
The issue with wrappers is exactly same as translation layers and compatibly layers. The game cannot be optimized for the native platform so will never run as well as a native port or the original platform.
If the license agreement has ran out between the two companies, the porting company may ask for more money to use their technology. Or the porting company may close down. The developer is unable to go else where because the technology is closed source and proprietary. This means you may stop getting patches or update for a game and the game has to be re-ported.
Wrappers could be seen more as a packaging technique than a full porting technique as they need a compatibility layer to function.
Examples: Wineskin, Cider, Virtual Programming eON.
Are Wrappers acceptable?
The performance of a compatibility or translation layer may be even better than a native port, because of simple reasons that you may be comparing a 10 year old optimized compatibility layer to a few month old less optimized native port. There are bound to be more bugs and issue in the native port. Ports always have the potential to be bad no matter what method they use. But the point is that the original developer has the code, retain control over distribution and are learning about new platforms. They actively help towards Linux development and can also bring forward parts of the port into their new game or back port into old games. They can hire new developers to fix or update their port without being tied down to a license agreement. It may take them time to perfect their port but they can still do it. Obviously in some cases it may be acceptable for a developer to use a translation layer to speed up an in-house port such as Valve’s togl, as long as the license requirements are open source or allow them to retain control over the code.
With every port that is not native there can be a damaging effect on OpenGL. If we begin to accept wrappers, translation layers and compatibly layers then developers will only target DirectX and give up on OpenGL support. As these layers are implemented after the newest DirectX release (and possibly via reverse engineering) support will always be behind in version or broken on some level. Especially with the advent of Vulkan there really should be no need for non-cross platform APIs such as DirectX or Metal, except to create vendor lock in. Obviously in the case of a significantly different GPU in the case of some older consoles, OpenGL or Vulkan may not be suitable but we are talking about ports from desktop operating systems which use exactly the same GPU.
Also optimization is not just about performance it can also be using platform specific features or adding platform specific options. Some console ports to Windows for example may lock the FPS to 30 and lack a FOV option, this would be a bad port. There may be some issues between Windows and Linux such as display mode switching (which WINE is really bad for - alt tabbing and finding your desktop is not in 800x600). I have also notice that some VP wrappers have issues with alt-tab where the viewport becomes like 20% in the bottom left corner - which may or not also be attributed to display mode switching of the original Window version. Features such as Xbox Live gaming or using posting messages to certain social networks which may not be available in the same way on Linux. Sometimes assets may need to be changed such as converting mp3s to ogg vorbis or videos to webm. Feral Interactive for example seem to care a lot about adding platform specific features. They have an “Extras” section in their game launcher which enable and disables iTunes and sets an away message in iMessage. Personally as a Linux user this does not really interest me but I can see that some people may want these features if they are available on one platform. Only native ports and engines can fix all these issue.
As with any non natively ported game. It may even be that the game developer is no longer allowed to sell the game after the license agreement with the translation layer or wrapper company has ran out. This leaves Linux gamers high and dry because they would no longer be able to buy the game. Current gamers may even be denied access to online gaming with other platforms due to the builds becoming out of sync. The developer would have to re-port the game from scratch with a new company.
When gamers get older they may want to play their old “retro games” in their moment of nostalgia. Most gamers expect that they pay for a game once and then will be able to play it forever. They may find that the game has been re-ported and they no longer “own” the game and have to re-buy the new in-house port.
The more developers we have learning about and developing directly for Linux the less complaints we will have on social networks about how they cannot install the OS, stability issues or how they coded in Objective-C and now cannot port their game easily. When games are given to wrapper companies it is one less developer who get to use and experience and care about Linux. Where the porting company pays to License the game and get X% of the profits on those platforms, the original developer is not supporting or caring about Linux at all, they do not bare any of the financial responsibility - it does nothing to help Linux progress as a platform.
Do not be fooled into thinking that because something is wrapped by VP that you are getting "support" from the game developer. You are not, you get support from VP (a third party) which is no different from using WINE.
Lets say in a hypothetical situation all large (non indie) game developers now rely on wrappers. They give up developing cross platform engines and just use DirectX and Win32/XBox APIs. The games developers now have no code base or skill base to fall back on and completely rely on wrappers for porting. Should agreements fall apart, VP want to charge more money it could actually spell the end of Linux gaming rather than the beginning.
In these situations where we decided to give up on a native ports because the performance was bad or through impatience. An open source solution such as WINE is a much better alternative to a proprietary wrapper. Money goes into development for WINE which you will always be able to run the game on and new patches or DLC on it will work straight away. In most cases a wrapper will be the same performance as the WINE build because they are very similar technologies. Money going to Virtual Programming is less money to Codeweavers and less money to WINE to add in DirectX 11-12 support. It is less money to other native porting companies, who may go out of business. If you can accept a wrapped port via close source proprietary technology it really is helping Linux as much as dual booting the Windows version. Wrapping is not a stable solution to Linux gaming.
This is why no matter how good the wrapper is we should only be asking for native.
We should be asking engine companies and developers to make native engines, and individual porters or porting companies to help port the older games natively. Article taken from GamingOnLinux.com.
It is not just about performance, there are many other factors that influence a “good” and a “bad” port. Also some ports can contribute to Linux in a more positive way than others.
I will give a quick explanation of the porting techniques and some of their advantages/disadvantages and then an explanation of my opinion on wrapped ports.
1. Native Engine.
The engine is already cross platform or ported during development and games are then exported to all platforms during the game development process, not after.
Games developers and artists usually do not have to do anything except export to the platform, QA test and report any bugs to the engine developers.
Platform specific bugs will be picked up by QA and fixed during the development process, usually with support from the original Engine developer such as Epic, Unity or Valve.
Bugs are fixed on all platforms at the same time and the engine can gradually be redesigned to be more cross platform and abstracted. Bugs found in one game will help the engine development and in turn can fix bugs in another game.
These engines are designed so that developers will either script in a language such as Javascript, C# or build to a specific cross platform API in C++. In most cases no platform specific code will be written by the developers.
For artists assets are designed to be easily exported to cross platform formats. Platform specific GUIs (Console/Desktop/Mobile) and settings/options may need to be created but this is easy to do with native builds.
One issue with native engine development can occur when the developer alters the engine source code themselves or by picking close source middleware or plugins that are not cross platform. This can usually be solved by building regularly for all platforms, picking cross platform middleware and trying to merge any upstream patches and changes in as soon as possible.
If for whatever reason they require a specific plugin which is not cross platform and no replacement can be found then the game may only be able to be released on one platform, this will be the same for all native porting techniques. As this occurs as part of the development process and not after it is simpler to fix with less risk to one specific platform.
Also with native engines there can still be performance issues, but as there is active support from the engine developer patches and changes can be made fairly easily and there is less stress and pressure on the developer to fix the issues themselves. A good example of this is OpenGL shader compiling. A well known issue with OpenGL is that shaders are compiled/optimized at first draw rather than when first created. This causes massive stutters especially with unique shader heavy engines. This means shaders ideally need to be pre-warmed. Separate shader objects does not entirely remove the performance penalty during first use but does speed up some compilation by removing the amount of shader program used and compiled. If an engine originally ships without this then there will be significant stutters on the Linux and Mac versions that do not appear on Windows. However as the native engine is always progressing is quite possible to cherry-pick the commits for SSO from the newer engine code. This shader issue is one of the reasons why Vulkan and SPRI-V will be very good for Linux, and without the support of Value and their development of Source 2 it may never have happened.
Even if a developer uses a pre built native engine but only builds for one platform and does not test or build for other platforms until after or near completion this would be classed in the “Native Port” section below. There are plenty of Unity developers which are falling into the trap of leaving their Linux and Mac exports until the last minute and finding they are having issues.
Examples: Unreal Engine 4, Unity, Source 2.
2. Native Port.
The game is ported after development (and possibly release) of one platform.
There can be issues with this is that there are certain engine techniques that do not translate well to all platforms. This can happen even with well abstracted engines that have not coded directly for one platform API (such as Win32).
Because the engine is not designed by the original developer and one platform is already finished development, it is difficult (but not impossible) to alter the engine to fit. There may also be certain middleware that is closed source and has not yet been ported to Linux. Support from the original engine developer may also have ended.
Along with the previously mentioned shader issue another difference can be in DirectX Constant Buffers have little penalty for mapping and updating them, but in OpenGL updating a Uniform Buffer every draw call can have a significant performance issues. An engine that is originally based around DirectX may not pre-warm shaders and significantly abuse per draw Constant Buffer updates. Redesigning the engine to support shader pre-warming and batching the constant buffers updates per frame or per object, may take a long time especially without support from the engine developer. It may also prevent the DirectX code from working properly and break the Windows build. This means Windows either needs to be fixed or the Linux code will diverge and need to be branched from the Windows code. Some of this can be elevated with the use of OpenGL 4 such as persistent mapped buffers and separate shader objects but there may still be worse performance compared to DirectX and this leaves out users of older GPUs or on the Mesa drivers.
The good thing is that whilst there are these issues, they can be fixed and the engine be updated over time, and new fixes for one engine can be back-ported or shared between developers.
As with native engines the game scripts and assets can be redesigned and optimised for the new platform creating platform specific GUIs. This may be more difficult if the art team has already left for a new project.
In most cases with a native port the developer either contracts out or ports in-house. The new code is usually owned by the developer and committed directly into their version control system. The developer is able to create new builds and fix bugs after the port has been complete. Patches are usually in sync with all platforms.
3. Native translation/abstraction layers and drop in replacement middleware.
Porters have access to the game source and the game is compiled natively but the original game code is largely untouched except for certain compilation fixes an bug fixes.
The game is then compiled against translation layers which are essentially native reimplementations of Win32 and/or DirectX or a console API. These layers are usually created by reverse engineering, lots of documentation/api reading, guesswork and many workarounds.
This has the same issues as true native ports in that certain DirectX features may not map well to OpenGL, except for the fact that it is now much more difficult to alter the original game code.
Redesigning the engine is definitely out of question and to fix the issues conditional compilation or certain work arounds might need to be used, which is harder to maintain than a well abstracted engine.
If the port is done by a third party they may have certain licensing agreements. This can be based on the porting company paying the original developer for the rights to distribute their game and they either get all or a percentage of profits for the ported platforms. So it is not possible for a developer to fix bugs on the platform or contract out the bug fix to a new developer they have to always go through the third party porter. One of the major disadvantages of this can be that patches become out-of sync with the original platform. e.g. The Linux DLC coming 6 months after the Windows DLC.
If for whatever reason the license agreement between the original developer and porter end, then the game has to be re-ported because the original developer has no access to the abstraction layer or middleware code.
A good example of the issue with this can be X3: Reunion from Linux Games Publishing. There are two versions of X3: Reunion, one that was done by LGP and then one that was re-ported internally.
Examples: Winelib, LGP.
4. Compatibility Layers.
The system translates the api calls as it is running and maps them to native implementations. The CPU architecture usually needs to be the same.
The porter has no access to the source code for the game and uses exactly the same binary and build as the original platform.
These are similar to translation layers in that they are reverse engineered and/or API reimplementations.
The advantage here is that along as the compatibly layer fully respects the original platforms API then any and all applications will be able to run very quickly with no cost.
The disadvantages can be performance issues and also issues if the original platform has some functionality that the new platform does not have. There can be the same issues as the native ports except now it is largely impossible to redesign the engine because there is no access to the code. Because of this a properly optimised native port or engine will always run better than a compatibility layer.
In most cases compatibility layers are meant to allow the user to run any software themselves and not meant for a third party porter to distribute an application. But it works for porting and distributing of some games where the code may be “lost” such as System Shock 2 as there is no other way.
Another advantage here for WINE is that it is open source so any changes and fixes help all Linux gamers. The good point about Crossover is that it is essentially a supported and stable version of WINE, so any money goes towards WINE development.
Examples: Crossover, Cedega and WINE.
5. Emulators.
A complete system is emulated with a separate OS or ROM running onto of the native OS. The CPU architecture can be completely different.
The advantage of this is it allows you to run games that were not developed for the current CPU architecture. Old consoles, 16 bit DOS games.
The disadvantage here is performance, even with a hardware virtualisation everything has to be translated and the port can never be optimised. This is why it is only really useful for low graphics applications or much older applications.
Examples: QEMU, Virtual Box, DOSBox.
7. Wrappers.
A compatibility layer is prebuilt and the original binary is wrapped in some way to allow executing as a native binary.
This could also include shipping a prebuilt version of WINE and having a script to load the executable.
The advantage is the same as compatibility layers and that the port is quicker release and patches may be in sync with the original platform. The added benefit is that the developer or porter has control over the specific compatibility layer version or technology that the user will use so can pick one that has the least issues.
The issue with wrappers is exactly same as translation layers and compatibly layers. The game cannot be optimized for the native platform so will never run as well as a native port or the original platform.
If the license agreement has ran out between the two companies, the porting company may ask for more money to use their technology. Or the porting company may close down. The developer is unable to go else where because the technology is closed source and proprietary. This means you may stop getting patches or update for a game and the game has to be re-ported.
Wrappers could be seen more as a packaging technique than a full porting technique as they need a compatibility layer to function.
Examples: Wineskin, Cider, Virtual Programming eON.
Are Wrappers acceptable?
The performance of a compatibility or translation layer may be even better than a native port, because of simple reasons that you may be comparing a 10 year old optimized compatibility layer to a few month old less optimized native port. There are bound to be more bugs and issue in the native port. Ports always have the potential to be bad no matter what method they use. But the point is that the original developer has the code, retain control over distribution and are learning about new platforms. They actively help towards Linux development and can also bring forward parts of the port into their new game or back port into old games. They can hire new developers to fix or update their port without being tied down to a license agreement. It may take them time to perfect their port but they can still do it. Obviously in some cases it may be acceptable for a developer to use a translation layer to speed up an in-house port such as Valve’s togl, as long as the license requirements are open source or allow them to retain control over the code.
With every port that is not native there can be a damaging effect on OpenGL. If we begin to accept wrappers, translation layers and compatibly layers then developers will only target DirectX and give up on OpenGL support. As these layers are implemented after the newest DirectX release (and possibly via reverse engineering) support will always be behind in version or broken on some level. Especially with the advent of Vulkan there really should be no need for non-cross platform APIs such as DirectX or Metal, except to create vendor lock in. Obviously in the case of a significantly different GPU in the case of some older consoles, OpenGL or Vulkan may not be suitable but we are talking about ports from desktop operating systems which use exactly the same GPU.
Also optimization is not just about performance it can also be using platform specific features or adding platform specific options. Some console ports to Windows for example may lock the FPS to 30 and lack a FOV option, this would be a bad port. There may be some issues between Windows and Linux such as display mode switching (which WINE is really bad for - alt tabbing and finding your desktop is not in 800x600). I have also notice that some VP wrappers have issues with alt-tab where the viewport becomes like 20% in the bottom left corner - which may or not also be attributed to display mode switching of the original Window version. Features such as Xbox Live gaming or using posting messages to certain social networks which may not be available in the same way on Linux. Sometimes assets may need to be changed such as converting mp3s to ogg vorbis or videos to webm. Feral Interactive for example seem to care a lot about adding platform specific features. They have an “Extras” section in their game launcher which enable and disables iTunes and sets an away message in iMessage. Personally as a Linux user this does not really interest me but I can see that some people may want these features if they are available on one platform. Only native ports and engines can fix all these issue.
As with any non natively ported game. It may even be that the game developer is no longer allowed to sell the game after the license agreement with the translation layer or wrapper company has ran out. This leaves Linux gamers high and dry because they would no longer be able to buy the game. Current gamers may even be denied access to online gaming with other platforms due to the builds becoming out of sync. The developer would have to re-port the game from scratch with a new company.
When gamers get older they may want to play their old “retro games” in their moment of nostalgia. Most gamers expect that they pay for a game once and then will be able to play it forever. They may find that the game has been re-ported and they no longer “own” the game and have to re-buy the new in-house port.
The more developers we have learning about and developing directly for Linux the less complaints we will have on social networks about how they cannot install the OS, stability issues or how they coded in Objective-C and now cannot port their game easily. When games are given to wrapper companies it is one less developer who get to use and experience and care about Linux. Where the porting company pays to License the game and get X% of the profits on those platforms, the original developer is not supporting or caring about Linux at all, they do not bare any of the financial responsibility - it does nothing to help Linux progress as a platform.
Do not be fooled into thinking that because something is wrapped by VP that you are getting "support" from the game developer. You are not, you get support from VP (a third party) which is no different from using WINE.
Lets say in a hypothetical situation all large (non indie) game developers now rely on wrappers. They give up developing cross platform engines and just use DirectX and Win32/XBox APIs. The games developers now have no code base or skill base to fall back on and completely rely on wrappers for porting. Should agreements fall apart, VP want to charge more money it could actually spell the end of Linux gaming rather than the beginning.
In these situations where we decided to give up on a native ports because the performance was bad or through impatience. An open source solution such as WINE is a much better alternative to a proprietary wrapper. Money goes into development for WINE which you will always be able to run the game on and new patches or DLC on it will work straight away. In most cases a wrapper will be the same performance as the WINE build because they are very similar technologies. Money going to Virtual Programming is less money to Codeweavers and less money to WINE to add in DirectX 11-12 support. It is less money to other native porting companies, who may go out of business. If you can accept a wrapped port via close source proprietary technology it really is helping Linux as much as dual booting the Windows version. Wrapping is not a stable solution to Linux gaming.
This is why no matter how good the wrapper is we should only be asking for native.
We should be asking engine companies and developers to make native engines, and individual porters or porting companies to help port the older games natively. Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Patreon
PayPal
Linux won't get enough marketshare, without AAA games first. And it will need to get almost every game.
Average user won't stay if they see a game coming out, that they wont to play badly but is windows only.
Last edited by alex_gol on 5 July 2015 at 7:56 pm UTC
Unfortunately, no. Ever heard of "design by committee"? There is a anecdote out there how two parties could not agree whether a packet length for a certain protocol should be 32 bit or 64 bit and ended up adopting 48 bit as a compromise solution.
The lack of a single powerful entity that says "stop! we're specifying it that way - and if your hardware cannot comply, too bad" was always a problem for OpenGL. Apple basically donated OpenCL to Khronos - why the heck OpenGL compute shaders were allowed to exist? I can guess that the reason was politics - some vendors did not want to support a competing GPGPU API and preferred less general approach. Now it's no wonder that Apple is pissed off and does its own thing.
Granted, OpenGL was exceptionally prone to lawyering due to its history. Arguably, it was designed with fragmentation in mind, and this fragmentation facilitated decision making akin to the above 48 bit joke - neither practical, nor satisfying for any of the parties involved. The sheer breadth of the API allowed vendors to go their own route while formally complying to the specification. Of course, this just pushed the problem to the developers who paid the real cost of the hardware compatibility, and it's no wonder that developers ran towards more "authoritarian", but also more clear and unambiguous APIs, happy to pay Microsoft for being a platform's policeman, because the price was still lower than doing it themselves.
Vulkan has better chances because the API is smaller (just a few % of the OpenGL in terms of function calls), but Khronos decision making is still a problem. Both Microsoft and Apple invite developers and vendors to discuss their upcoming API, so they are not designing it single-handedly, but they still hold the decisive voice. Khronos, on the contrary, is the European Union of the architecture boards... Let's hope they will settle on something before Metal and DX12 gain wider adoption.
I did, but I will not do it that often anymore. Honestly I was so glad that I supported many games I never wanted to play in the first place, because they didn't interest me.
I'm not going to do this anymore. I will support games that run natively on my favorite platform and devs that do try to make them working great but only if the game itself interests me.
I think that's one big problem, there is such a mass of new games coming to Linux right now, that the already small market divides itself naturally, hence leading to lower sales for individual games.
Depends on the game, really. And on the performance of the port. Because if the port is running abysmal I do not care whether it's native or a wrapper port, I'll request a refund, because I don't support bullshit.
And actually, I would like to see devs working on Linux (native or wrappers) ports period. It happened the same with Witcher 2; disaster initially while perfectly playable now.
So if native is not possible for whatever reason, I'll take the wrapped one, pay the guys and say thanks either way.
What year is it?
That was gold :).
Although Commentor OP is clearly radical or troll - I agree that we should buy as we please. And you know what? I've been buying and playing games even in the $20-30 range just because the Arch Linux people of my house are glad to see native games that are well crafted.
The fate of the future is sealed, Linux is a beast that is made to outlive any Corporation, Company or Group because of its openness. Windows & Mac on the other hand require lockin to their ecosystem. If you don't trust them or like the decisions they're making? Tough. Linux on the other hand requires that a governing organization listen to their users as the OS is largely not owned by any specific group - users have a bigger say to get a middleground between the "tough luck" and "total disordered dysfunctional democracy ". Valve are the gate keepers of this new Steamy world, but their power doesn't allow them to make radical and unethical choices with no consequence.
How do you decide what an "older" game is.
A game ported after release? A game where the code is lost?
Personally for games that either the code is lost or have some unportable middleware I would rather have a wine wrapped version simply because wine is open source. Bug fixes to wine help us all but bug fixes to eon help only one company.
Older games (talking 90s to early 2000s) = whatever works best on Linux.
I agree, but Linux users are pretty hyper-sensitive to criticism of the platform too.