5 ms·

My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. The

by bdz 8y ago

My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. These can disappear

jchw 8y ago
More likely, this will enable existing titles to run on Linux, making it easier to sell Linux machines like Valve's Steam boxes. Meanwhile, Valve can incentivize native ports on their platforms through many means, so I don't think an OS/2 situation is likely. Also, having a good DirectX 12 implementation on top of Vulkan will likely be useful the same way that Vulkan on top of Metal is useful for macOS ports. Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.
- c487bd62 8y ago
  Not to mention that it acts as a compatibility layer for older games that don't run on Windows 10 and others that will stop working as they remove more and more legacy code/features. Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
  - jchw 8y ago
    This would be nice, but I won't hold my breath too much: Valve is invested in current technologies like DX11 and DX12 emulation, whereas it'd be nice to see better emulation of D3D8/9 and DDraw if possible.
    - c487bd62 8y ago
      Things will only get better from now on (or as long as the money keeps flowing). https://github.com/disks86/VK9 https://github.com/disks86/VK9 https://github.com/doitsujin/dxvk/issues/551 https://github.com/doitsujin/dxvk/issues/551 https://github.com/doitsujin/dxvk/pull/541 https://github.com/doitsujin/dxvk/pull/541
      - jchw 8y ago
        Wow... Nice. I had always dreamed of commercially-supported Wine Direct3D improvements, and there's hardly a better company to invest than Valve. Valve definitely is willing to make longer term plays, especially looking at how long they've been working with Linux in general. Hope to see older titles improve as work goes on.
    - oliwarner 8y ago
      Proton is still Wine at its core. It's been handling that stuff for ages.
    - buovjaga 8y ago
      In the original announcement they say since 2016 they have been working with CodeWeavers on areas including "Many wined3d performance and functionality fixes for Direct3D 9 and Direct3D 11" https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561 https://steamcommunity.com/games/221410/announcements/detail...
    - dkeeton 8y ago
      ts-ddraw and cnc-ddraw provide a decent base for certain ddraw games C&C95, Red Alert, Warcraft 2, C&C Tiberian Sun, and Red Alert 2. This is Warcraft 2 with cnc-ddraw using xbrz: https://i.imgur.com/sG1DC23.png https://i.imgur.com/sG1DC23.png https://github.com/CnCNet/cnc-ddraw https://github.com/CnCNet/cnc-ddraw https://github.com/CnCNet/ts-ddraw https://github.com/CnCNet/ts-ddraw Use case https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tiberian_sun_full_game_download_now_available/ https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tib...
      - vasili111 8y ago
        > C&C Tiberian Sun I remember that music! Good old days :)
      - bisby 8y ago
        Only 1321 fps? Compatibility layers always add such a terrible performance hit.
    - simion314 8y ago
      Directx9 workf fine in Wine already, the problems were with Directx11, there are some obscure games that are not working on Wine, some games need specific fixes since they were working on Windows by mistake. I could not play Oblivion on Windows10 but worked on Wine for me.
- LoSboccacc 8y ago
  and if at some point linux becomes good enough, companies might start targeting dxvk directly instead of wine. that alone would remove a lot of friction to proper ports.
zaarn 8y ago
I think I can live with devs targeting Wine on Linux instead of Linux directly, it saves them a lot of resources since most will be invested into Windows support. And yes, maybe it means we get less Linux native, I don't mind either. If it works on Linux and is supported on Linux, even if it's just via Wine, that's all I want.
- SmellyGeekBoy 8y ago
  Indeed. Modern software has plenty of layers of abstraction to begin with. One more isn't going to break the bank. (I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
  - zaarn 8y ago
    Most games will be running on an engine the studio bought, if not, it's usually one maintained by an in house team. Which is, I suspect, the reason why some gamedevs are hesistant. For Linux they not only need the QA track and development resources but might have to redevelop some engine customizations for Linux or the engine might not even support Linux at all. They're two steps removed from the people who would be responsible for making the engine work on Linux at all.
  - matthewaveryusa 8y ago
    We're moving full-steam ahead to a client OS like qubes where every application is emulated on top of the original operating system it was developed for. We're pretty much already there for servers with containers. While internally each application will be a security nightmare, one-level up it's a godsend! I wouldn't be surprised if that qubes-like OS will have a kernel that runs WASM natively. Emulation galore turtles all the way down
- tfha 8y ago
  I know more than a few people who prefer Linux but boot windows for gaming. The biggest reason they don't make a bigger effort to support Linux games is because there aren't enough options. More emulation means more traction for Linux gaming. If windows can be dropped as a requirement for serious gaming, the Linux userbase will grow significantly, and this will help turn the tide.
dtech 8y ago
Do we care how the Linux compatibility is achieved? If the end result is the game is available on Linux, stable and performant why should I give a damn that it uses Wine internally any more than whether is uses Unity or python or whatever?
aiCeivi9 8y ago
This already happens. Gnomoria had just bolted on Mono. And there were many games that simply used winelib.
- giancarlostoro 8y ago
  Gnomoria running Mono? It's not a .NET project but a Java one, might you be confusing it with Terraria or something?
maskros 8y ago
This may actually be better in the long run. Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym. A windows binary targeting Wine will not stop working just because some shared system library has been updated.
- AnIdiotOnTheNet 8y ago
  > Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model. Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
  - yrro 8y ago
    Well, now we have flatpak and snap to work around the "broken" software distribution models of most distros... That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
    - AnIdiotOnTheNet 8y ago
      And before them we had GNUStep Application Bundles, ROX Filer AppDirs, and Klik (now AppImage). Flatpak and Snap do have some "advantages" over those from a Linux Desktop Community perspective though: They're incredibly over-engineered and they're the same idea implemented twice. > That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.
LambdaComplex 8y ago
Even Steam itself is "just enough." Off the top of my head, the Steam Linux client: * Ignores flags (so `steam --help` for instance just starts Steam the same way `steam` does) * Ignores signals (including SIGTERM, I believe) * Screws up my tiling window manager sometimes, so it probably ignores EWMH I personally think Valve needs to just separate the core Steam functionality into some backend and allow users to write their own frontends. =========== And now for an unrelated "Valve/Linux" rant while I'm here: Half-Life: Opposing Force has been unbeatable on Linux since its release. The final boss's death animation plays too quickly and the trigger to change to the next map never occurs. There's been an issue open on the ValveSoftware/halflife GitHub repo about this since 2013. And the real kicker? Someone (not a Valve employee) actually went through the source code and determined the cause of the problem[0]. It still hasn't been fixed. =========== Screw it, I'll give you one more. Last time I checked, it was impossible to get Half-Life Dedicated Server running through steamcmd[1][2], because the necessary files never finished downloading. When I was trying to get this working, I eventually found a GitHub repo containing modified versions of some files that you could use to make steamcmd actually download everything. I was unable to find this repo again while writing this comment (but I didn't put that much effort into it). </rant> 0. https://github.com/ValveSoftware/halflife/issues/917#issuecomment-241015072 https://github.com/ValveSoftware/halflife/issues/917#issueco... 1. https://github.com/ValveSoftware/halflife/issues/928 https://github.com/ValveSoftware/halflife/issues/928 2. https://steamcommunity.com/discussions/forum/14/1291816880503781252/ https://steamcommunity.com/discussions/forum/14/129181688050...
- s3krit 8y ago
  Thanks for the heads up on the OpFor issue - I just started playing through the original HL games again.
- bopbop 8y ago
  There's an open source version of the Half Life engine called Xash3d which is feature complete: https://github.com/FWGS/xash3d https://github.com/FWGS/xash3d It's also got an excellent Android port: https://www.moddb.com/games/xash3d-android https://www.moddb.com/games/xash3d-android
shazow 8y ago
I suspect you're right in the short term, but in the long term it will push more users to adopt Linux and maybe eventually devs will pay more attention.
tomc1985 8y ago
Most (if not all, now) of the major engines (Unreal, Unity, ???) export native binaries for Windows, Mac, and Linux. This seems more for getting legacy titles included. Even without emulation it is impressive how much of Steam's library is available on Linux.
jandrese 8y ago
If it means devs go back and tweak the one or two minor issues that prevent their game from working on Wine then I can't complain that much.

by bdz 8y ago

My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. These can disappear

jchw 8y ago

More likely, this will enable existing titles to run on Linux, making it easier to sell Linux machines like Valve's Steam boxes. Meanwhile, Valve can incentivize native ports on their platforms through many means, so I don't think an OS/2 situation is likely. Also, having a good DirectX 12 implementation on top of Vulkan will likely be useful the same way that Vulkan on top of Metal is useful for macOS ports. Of course... it's still a long and difficult road for Valve here, given how well emulation will need to work to accomplish this.

c487bd62 8y ago
Not to mention that it acts as a compatibility layer for older games that don't run on Windows 10 and others that will stop working as they remove more and more legacy code/features. Some say there are games that have noticeable stutters or bottlenecks on Windows that doesn't share the same issues on Wine.
- jchw 8y ago
  This would be nice, but I won't hold my breath too much: Valve is invested in current technologies like DX11 and DX12 emulation, whereas it'd be nice to see better emulation of D3D8/9 and DDraw if possible.
  - c487bd62 8y ago
    Things will only get better from now on (or as long as the money keeps flowing). https://github.com/disks86/VK9 https://github.com/disks86/VK9 https://github.com/doitsujin/dxvk/issues/551 https://github.com/doitsujin/dxvk/issues/551 https://github.com/doitsujin/dxvk/pull/541 https://github.com/doitsujin/dxvk/pull/541
    - jchw 8y ago
      Wow... Nice. I had always dreamed of commercially-supported Wine Direct3D improvements, and there's hardly a better company to invest than Valve. Valve definitely is willing to make longer term plays, especially looking at how long they've been working with Linux in general. Hope to see older titles improve as work goes on.
  - oliwarner 8y ago
    Proton is still Wine at its core. It's been handling that stuff for ages.
  - buovjaga 8y ago
    In the original announcement they say since 2016 they have been working with CodeWeavers on areas including "Many wined3d performance and functionality fixes for Direct3D 9 and Direct3D 11" https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561 https://steamcommunity.com/games/221410/announcements/detail...
  - dkeeton 8y ago
    ts-ddraw and cnc-ddraw provide a decent base for certain ddraw games C&C95, Red Alert, Warcraft 2, C&C Tiberian Sun, and Red Alert 2. This is Warcraft 2 with cnc-ddraw using xbrz: https://i.imgur.com/sG1DC23.png https://i.imgur.com/sG1DC23.png https://github.com/CnCNet/cnc-ddraw https://github.com/CnCNet/cnc-ddraw https://github.com/CnCNet/ts-ddraw https://github.com/CnCNet/ts-ddraw Use case https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tiberian_sun_full_game_download_now_available/ https://www.reddit.com/r/linux_gaming/comments/97l5bk/cc_tib...
    - vasili111 8y ago
      > C&C Tiberian Sun I remember that music! Good old days :)
    - bisby 8y ago
      Only 1321 fps? Compatibility layers always add such a terrible performance hit.
  - simion314 8y ago
    Directx9 workf fine in Wine already, the problems were with Directx11, there are some obscure games that are not working on Wine, some games need specific fixes since they were working on Windows by mistake. I could not play Oblivion on Windows10 but worked on Wine for me.
LoSboccacc 8y ago
and if at some point linux becomes good enough, companies might start targeting dxvk directly instead of wine. that alone would remove a lot of friction to proper ports.

zaarn 8y ago

I think I can live with devs targeting Wine on Linux instead of Linux directly, it saves them a lot of resources since most will be invested into Windows support. And yes, maybe it means we get less Linux native, I don't mind either. If it works on Linux and is supported on Linux, even if it's just via Wine, that's all I want.

SmellyGeekBoy 8y ago
Indeed. Modern software has plenty of layers of abstraction to begin with. One more isn't going to break the bank. (I genuinely can't believe I'm posting this comment completely un-ironically, but here we are).
- zaarn 8y ago
  Most games will be running on an engine the studio bought, if not, it's usually one maintained by an in house team. Which is, I suspect, the reason why some gamedevs are hesistant. For Linux they not only need the QA track and development resources but might have to redevelop some engine customizations for Linux or the engine might not even support Linux at all. They're two steps removed from the people who would be responsible for making the engine work on Linux at all.
- matthewaveryusa 8y ago
  We're moving full-steam ahead to a client OS like qubes where every application is emulated on top of the original operating system it was developed for. We're pretty much already there for servers with containers. While internally each application will be a security nightmare, one-level up it's a godsend! I wouldn't be surprised if that qubes-like OS will have a kernel that runs WASM natively. Emulation galore turtles all the way down
tfha 8y ago
I know more than a few people who prefer Linux but boot windows for gaming. The biggest reason they don't make a bigger effort to support Linux games is because there aren't enough options. More emulation means more traction for Linux gaming. If windows can be dropped as a requirement for serious gaming, the Linux userbase will grow significantly, and this will help turn the tide.

dtech 8y ago

Do we care how the Linux compatibility is achieved? If the end result is the game is available on Linux, stable and performant why should I give a damn that it uses Wine internally any more than whether is uses Unity or python or whatever?

aiCeivi9 8y ago

This already happens. Gnomoria had just bolted on Mono. And there were many games that simply used winelib.

giancarlostoro 8y ago
Gnomoria running Mono? It's not a .NET project but a Java one, might you be confusing it with Terraria or something?

maskros 8y ago

This may actually be better in the long run. Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. If you're shipping Linux binaries, you really should be linking statically! Any shared libraries you need, like OpenGL, you should load manually with dlsym. A windows binary targeting Wine will not stop working just because some shared system library has been updated.

AnIdiotOnTheNet 8y ago
> Almost all proprietary Linux binaries I've seen shipped in the wild link to shared system libraries -- and tend to fall apart when the system libraries are a different version than expected. This is probably the biggest problem with Linux as a desktop, and the sad reality is that it will never ever be fixed because the community has an almost religious adherence to their completely broken platform model. Maybe if Valve puts enough effort into WINE, the future of the open source desktop will be WINE on top of the Linux kernel? That'd be... tolerable.
- yrro 8y ago
  Well, now we have flatpak and snap to work around the "broken" software distribution models of most distros... That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. There's really no excuse to not do things properly!
  - AnIdiotOnTheNet 8y ago
    And before them we had GNUStep Application Bundles, ROX Filer AppDirs, and Klik (now AppImage). Flatpak and Snap do have some "advantages" over those from a Linux Desktop Community perspective though: They're incredibly over-engineered and they're the same idea implemented twice. > That said, if you ship an application that depends on system libraries then you're just setting yourself up for problems. Only on Linux, which is kinda my point. Other platforms are actually, you know, platforms.

LambdaComplex 8y ago

Even Steam itself is "just enough." Off the top of my head, the Steam Linux client: * Ignores flags (so `steam --help` for instance just starts Steam the same way `steam` does) * Ignores signals (including SIGTERM, I believe) * Screws up my tiling window manager sometimes, so it probably ignores EWMH I personally think Valve needs to just separate the core Steam functionality into some backend and allow users to write their own frontends. =========== And now for an unrelated "Valve/Linux" rant while I'm here: Half-Life: Opposing Force has been unbeatable on Linux since its release. The final boss's death animation plays too quickly and the trigger to change to the next map never occurs. There's been an issue open on the ValveSoftware/halflife GitHub repo about this since 2013. And the real kicker? Someone (not a Valve employee) actually went through the source code and determined the cause of the problem[0]. It still hasn't been fixed. =========== Screw it, I'll give you one more. Last time I checked, it was impossible to get Half-Life Dedicated Server running through steamcmd[1][2], because the necessary files never finished downloading. When I was trying to get this working, I eventually found a GitHub repo containing modified versions of some files that you could use to make steamcmd actually download everything. I was unable to find this repo again while writing this comment (but I didn't put that much effort into it). </rant> 0. https://github.com/ValveSoftware/halflife/issues/917#issuecomment-241015072 https://github.com/ValveSoftware/halflife/issues/917#issueco... 1. https://github.com/ValveSoftware/halflife/issues/928 https://github.com/ValveSoftware/halflife/issues/928 2. https://steamcommunity.com/discussions/forum/14/1291816880503781252/ https://steamcommunity.com/discussions/forum/14/129181688050...

s3krit 8y ago
Thanks for the heads up on the OpFor issue - I just started playing through the original HL games again.
bopbop 8y ago
There's an open source version of the Half Life engine called Xash3d which is feature complete: https://github.com/FWGS/xash3d https://github.com/FWGS/xash3d It's also got an excellent Android port: https://www.moddb.com/games/xash3d-android https://www.moddb.com/games/xash3d-android

shazow 8y ago

I suspect you're right in the short term, but in the long term it will push more users to adopt Linux and maybe eventually devs will pay more attention.

tomc1985 8y ago

Most (if not all, now) of the major engines (Unreal, Unity, ???) export native binaries for Windows, Mac, and Linux. This seems more for getting legacy titles included. Even without emulation it is impressive how much of Steam's library is available on Linux.

jandrese 8y ago

If it means devs go back and tweak the one or two minor issues that prevent their game from working on Wine then I can't complain that much.