Support us on Patreon
PayPalArmello, a grim fairy-tale board game from League of Geeks no longer advertises that it supports Linux and macOS due to their new party system that landed with the cross-play update.
In the news post they mention how there's "No Party Functionality (including Private Games) on MacOSX & native Linux. Due to the severity of this one, we've removed any advertising of support for Linux & Mac from Steam (and shortly Humble Bundle), though folks can still purchase and play those versions.".
Giving a little more detail on their official site it mentions how "The service provider we use for Armello’s multiplayer infrastructure has decided to cease support for their party services on MacOSX and Linux. Unfortunately, this means that Party Functionality, including Private Multiplayer, is no longer available in Armello on MacOSX and native Linux platforms." but they don't go on to name whatever company that is.
For the Native Linux and macOS versions, they're still functional and up to date they just don't have the new party system or private matches. For Linux users though you can use Proton to run the Windows version, which fully works. It also has a Steam Deck Playable rating, which uses Proton now too.
This isn't the only game to go a similar route, with ARK: Survival Evolved recently putting the Linux Native version behind a Beta.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
EagleDelta Jul 14, 2022
Quoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
9 Likes, Who?
Mountain Man Jul 14, 2022
I honestly don't have a problem with using Proton to play games that are targeted for Windows since it generally works flawlessly (and in some cases, playing through Proton offers better performance than playing a native Linux version, as counter intuitive as that might seem). What gives me pause is when developers treat Proton as an unsupported extra, where they're happy to take our money but then tell us we're on our own if we encounter any problems.
5 Likes, Who?
Quoting: EagleDeltaQuoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
Last edited by Eike on 14 July 2022 at 4:23 pm UTC
7 Likes, Who?
EagleDelta Jul 14, 2022
Quoting: EikeQuoting: EagleDeltaQuoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
That's the definition of what APIs do - they map calls to something else so that the programmer doesn't need to know all the details under the surface. Hence why web APIs are so popular because they are so ubiquitous.
It seems the Linux Gaming community wants to change the definition of APIs for WINE/Gaming vs everything else. A Web application isn't "native" either, but the reality is that JS/Electron APIs are mapping to System Calls. Which is what C, Python, Ruby, Go, Rust, etc APIs do as well for desktop/CLI applications.
In reality, DXVK is a DX API for Vulkan, WINE is a Windows API for all platforms, faudio is an xaudio API for all platforms, so on and so forth
Last edited by EagleDelta on 14 July 2022 at 6:24 pm UTC
3 Likes, Who?
soulsource Jul 14, 2022
Quoting: EikeThe program code is native already (x86 instruction set with AMD64 extensions). WINE contains an independent reimplementation of various libraries shipped with Windows. So, instead of calling functions in Microsoft's Direct3D implementation (as example), programs running under WINE call into WINE's Direct3D implementation (which, opposed to Microsoft's implementation, internally uses other graphics libraries like Vulkan to make the code independent of graphics driver - therefore the term "mapping").Quoting: EagleDeltaQuoting: elmapulbecause they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
This is not only true for graphics libraries though, but for almost (WINE isn't 100% complete) all libraries that come with Windows, what includes low-level libraries for accessing basic system functionality.
In other words, the code is still running 100% native, it just might show different performance/behaviour to Windows because the libraries might be faster/slower, and the Windows API documentation might not always perfectly reflect real-world behaviour of Windows libraries (and of course there could be bugs in WINE).
Also, EXE/DLL is just a file format. The distinction if a program's machine code is stored in an ELF file or an EXE file is similar to the one if an MP3 stream is stored inside an MKV or an AVI file. WINE contains a reader for EXE files, and if you want to, you can set up your Linux kernel to just use WINE's EXE reader if you try to launch an EXE file directly.
9 Likes, Who?
We've done it. We've actually reached a point in the debate where not only is using Proton better than native titles, it's all actually been native the whole time.
6 Likes, Who?
soulsource Jul 14, 2022
Quoting: soulsource
When writing my posting, I wondered if I should mention that I am programming for 38 years and that I'm professional software developer for over two decades. It seems I should have.
I know all you've written. But you left out that every single call into the Windows(!) API has to be translated, during runtime. It is not native, it is translated into native. Like a human language interpreter doesn't make English native German - they translate.
6 Likes, Who?
Quoting: soulsourceQuoting: RaabenWe've done it. We've actually reached a point in the debate where not only is using Proton better than native titles, it's all actually been native the whole time.Who said it's better? The "native" discussion is actually answered quite well on the WINE FAQ.
You might want to read 5.8.
Ah, 6.6.3 of eben better:
Another option is to use a shell script to call a native application. Save it as run_linux_program...
Last edited by Eike on 14 July 2022 at 7:46 pm UTC
0 Likes
See more from me