Whereas my library of virtual assets will probably evaporate into ether before I'm even retired.
This feels like a strange thing since the Epic engine is available on Linux (I used it for dev just a couple of months ago).
I am not disputing the statement, the op makes a good case for atleast Tim being quite anti-Linux. I just feels really weird that the game store wouldn't ever get to a platform the engine is already on. It feels short sighted by Epic. Or I guess it just isn't worth the investment...
Pulling support for a client of a competitive online game like Rocket League is fundamentally closing the game to those players - as they will be unable to compete online with other players (be it on PC or on the other platforms).
I really don't like Epic's change in behaviour here - It's quite disheartening since when they used to release first party Linux builds of their products ('Unreal Tournament 2004', and the recently cancelled upcoming 'Unreal Tournament' had Linux client releases), and they were one of the few big name game dev houses to actively support Linux clients.
If there was a market for Linux games Epic wouldn't have pulled Linux support. There is no money in Linux gaming, so many companies have started to pull back on supporting Linux after years of experimenting.
Probably much simpler just to make a solid Windows build that plays nicely with WINE.
Let alone MacOS, which is more supported than Linux but has comparatively much poorer hardware stats.
I have invested the time in setting up a Windows VM w/ PCI passthrough in order to play some games with friends. So I am not a hardline free software user or unwilling to use Windows for playing games.
But when a distributor and developer is openly hostile to the platform even as it's gaining traction among other developers (Valve, Google, etc), I am certainly willing to not buy their games anymore as a somewhat political stance. There are plenty of games that run on Linux for me to spend my time and money on.
Mostly technical speculation: The horrible binary compatibility story of Linux userland.
Socio-technical speculation because everything is now multiplayer: Less effective DRM on Linux means more cheaters ruining the game for others, in the worst case losing more players than Linux adds.
I would love that you be right. And by far, I strongly prefer physical media.
However, physical media is no guarantee either.
- Sometimes, the pain is on purpose: some apps require an online activation, and the corresponding service, 30 years later, is not available anymore.
- Sometimes, it's a lack of foresight from the developers (i.e overzealous Windows version checks, refusing newer versions).
- Sometimes, it's plain dumb stupidity (the installer is a 16-bit windows executable).
If you're not convinced, I suggest you try installing, say, Wipeout XL (for Windows 95) on a recent laptop (spoiler: at this point it's easier to play the PSX version on an emulator).
I think that Epic Killing Linux native is a shame but I also think that Valve has a long plan to make it a viable platform, and it's only begun, where many assumed they hit and missed.
The fact their VR headset will run on Linux too...
It looks like this won't matter too much to future of Linux gaming is all I'm saying.
If money and users are there, it's a different ballgame.
Other than Unreal (the game), there was hardly any big effort to support GNU/Linux from Epic side.
In case you missed it, that was the point of Steam Machines, and the respective distribution.
A mere 1% of Valve customers.
How hard is it to set up windows 95 in a vm, basically an emulator?
This has been effectively solved by three different tools. Take your pick from:
* Appimages
* Snaps
* Flatpaks
Naturally they all have their own upsides and downsides, but if the only thing holding you back from shipping to linux is concerns about fiddling with shared libraries, just pick one at random and move on. I suggest appimages as feeling closest to a fat binary without triggering various licence clauses, deliver it like it's an exe.
Graphics card driver issues largely stopped being a problem about 4 years ago, with both major graphics card manufacturers committing to open source drivers.
Packaging for multiple distributions is a problem that I would call "solved" for the past ~2 years, see my comment here: https://news.ycombinator.com/item?id=19844241
Exclusivity has no place on a decentralized market. When Sony and Microsoft do it, it’s still reprehensible, but understandable. This is inexcusable. People defending such deals (including Sony’s or Microsoft’s or Atari’s) are idiots.
Valve also use HTML/CSS (or some form of it) for their game UIs using Panorama, but this doesn't use any form of web browser from my knowledge.
So where is the great hardware video decoding and the GL features fxgl was capable of?
I understand where these companies are coming from. I would too love to have more games available to me on OS X but the simple fact is there are not enough customers to spend money to develop directly for it or even contract out to a software house to write a wrapper. Let alone how many complain how much the games or DLC cost are worse on some platforms compared to others.
Now it is more profitable to get cross platform with PC and game consoles.
I've built longer lasting pure linux binaries that use SDL with just gcc myself
> To clarify, Easy Anti-Cheat still provides native Linux support and will continue to do so. Earlier comments by a partner reflect ordinary day-to-day prioritization decisions on anti-cheat issues across all platforms and not any change in long-term priority for Linux.
https://arstechnica.com/gaming/2016/10/you-can-now-claim-you...
This is just my few pennies about that train of thought.
Though certainly they've been doing a lot of work behind the scenes with Proton now. I'm not sure where Proton leads quite yet other than making their existing Linux user base very happy. It's certainly increased the stickiness for me.
Indeed.
I feel like Electron encourages bad practice by allowing the developer to avoid the work of learning to write a native desktop app in favour of offloading the trade-offs of this decision onto their end-users in the form of poorly performing, bloated crap.
Physical media + online DRM is as bad as online-only.
Technology advancement (e.g., remote changes to blackbox products) makes many abuses easier than they used to be, and market forces don't seem to be working well enough, so I think we need strength of law as a check on abuses.
We will see over the next year I guess.
Usually, clauses in EULA's regarding forced arbitration protect companies from being sued for such nonsense, but seeing as how no such agreement has been made by these users between them and Epic, I don't see how it can be avoided legally. Those agreements were made with Valve.
If I suddenly find that I can no longer play Rocket League on Linux as a result of this, I'll be first in line.
If it uses GPU rendering, possessing physical media doesn't mean much. GPU vendors aren't that diligent about making sure old games run properly on their current hardware offerings.
Even for physical media for console games, patches DLC are delivered through the console's online service. Once that ends, as it has for the PSP and original Xbox, you're left with the game as it was originally released with whatever bugs it contains.
That could be to support Android or game consoles like the Switch.
That’s why I prefer gog over steam, downloading complete offline installers, and keeping them backed up. This way is even more reliable than buying games on physical media. Due to anti-piracy measures, often you can’t easily back up CDs or DVDs.
The compatibility situation has improved a lot, thanks to Vista. Windows Vista required D3D9-capable GPU, actually used it to render desktop, and Microsoft’s GUI stack uses the hardware too, e.g. modern WPF is still based on DX9 because compatibility reasons.
While GPU vendors indeed don’t care about gamers running 10 years old games, they can’t ignore business customers running 10 years old LoB software. As a side effect, even very slow (by modern standards) integrated Intel GPUs are usually quite good at running older DX9-based games.
I can only think of 2 possible reasons-- (1) the support costs are too high for the number of players (online competitive game, I'm sure there's quite a bit of dev time involved in securing the clients & preventing cheating that is Linux-specific) (2) Valve is supporting Linux, epic is busy feuding with valve, and this is similar to a petty toddler breaking their toy so they don't have to share.
Could be either, but I don't see how market penetration of windows in Asia could explain it
So the solution is to stay on a legacy kernel, with the security risks it entails, while my Windows 10 can perfectly make use of the DX 11 drivers.
There was a lot of complaining online, but the class action was a minor inconvenience and they now have a pretty solid lead with the ps4.
Sometimes bits rot, and the media becomes unreadable. Sometimes you're able to back it up, sometimes not.
Sometimes hardware and software incompatibilities appear. I built a late 90s/2000 era PC for that period of PC gaming (Windows 98, CRT). Other times, you get lucky and it's fixed: Freelancer won't run on Vista, but will on 7.
AMD's low-middle tier hardware is known to be mediocre, their drivers are known to be poor, and they're also known to drop support for hardware much faster than their competitors.
Yeah, you can run Linux on nearly anything.. but that doesn't mean you should try to sit in front of an old machine running old low quality components from manufacturers that don't support their low margin products.
You never did give your graphics card model number, but according to this[1] page the Brazos platform had two codename variants for laptops and notebooks: Ontario and Zacate. Hondo and Desna were exclusively for tablets. There were no variants for desktops.
According to this page[2] that puts your card somewhere in the Radion HD 6xxx or HD7xxx driver set, and the only references to Ontario are the Radeon HD 6290 and the Radeon HD 7340.
If you go to the AMD drivers download page[3] you'll discover that both of these cards have dropped off the bottom of the list of supported cards in their respective driver categories.
Now hey, maybe your card is a slightly newer model and it's still in that download list. I don't know, since I don't know your exact card model. But my 10 seconds of research says that actually it's probably not supported any more. If I'm wrong about that then you're pretty god damn close to the cliff edge at this point.
[1] https://en.wikipedia.org/wiki/AMD_Accelerated_Processing_Uni... [2] https://en.wikipedia.org/wiki/Radeon_HD_6000_Series [3] https://www.amd.com/en/support
My kernel line is (I disable the spectr/meltdown mitigations so ignore those parts):
root=/dev/mapper/ssd-arch--root rw intel_iommu=on iommu=pt i915.enable_guc=3 i915.disable_power_well=0 i915.enable_psr=1 i915.enable_fbc=1 i915.enable_rc6=1 pci=nomsi,noaer pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
The XML for the VM I configured in virt-manager can be found here:I don't think has any significant modifications. Eventually I want to switch over to using the newer q35 architecture. The only issues I've had with the VM are some audio glitches in some games and it has recently had issues with hugepages so I've had to disable that.