Theupdate - which directly addresses developers with games on Steam - details how the team has worked in partnership with Epic to make it "simple" for PC games that use EAC to add Steam Deck support, which should, in turn, see more compatible games added to the upcoming handheld system.
"Our team has been working with Epic on Easy Anti-Cheat + Proton support over the last few months, and we're happy to announce that adding Steam Deck support to your existing EAC games is now a simple process, and doesn't require updating game binaries, SDK versions, or integration of EOS," the update states (thanks, PCGN).
Though Valve expressed plans to make EAC games compatible several months back, some developers intimated that the matter was "far more complex than first suspected" and may not have been possible ahead of Steam Deck's release. But now the issues have seemingly been rectified, it should hopefully make it easier for devs using EAC to get their games onto Steam Deck. Popular games that run Easy Anti-Cheat include Halo: The Master Chief Collection, Rainbow Six Siege, and Epic's own Fortnite.
Consequently, from Monday 24th January the team is "going to start" submitting Deck Verified test data for tested titles that use those anti-cheat systems, inviting developers to choose whether or not they want Valve to assess the current build of their PC game for Steam Deck, or submit a new one.
none except they are never gonna try to fix it. Steam try to push that and have support for anti-cheat in kernel so wine could run anti-cheat software without any modification. The first working solution could be considered like cheating and so it will never be support. The kernel with anti-cheat support is suposed to land in 5.11 If iu want to learn more this video could explain things
However, one setback in buying the same is the missing support for different anti-cheat mechanisms as it runs Linux (SteamOS). Nevertheless, the gaming scene on Linux is improving thanks to Proton, and anti-cheat companies have started noticing Steam Deck and enabling anti-cheat support for different games.
Since the problem here is related to custom Linux kernel, many people suggested that Fortnite could only be made available for signed kernels or the custom SteamOS 3.0 kernel for the game to be playable on Steam Deck.
Abubakar is a Linux and Tech Writer. Hailing from a Computer Science background, the start of his love for Tech dates back to 2011, when he was gifted a Dell Inspiron 5100. When he's not covering Tech, you'll find him binge-watching anime and Tech content on YouTube or hunting heads in competitive FPS games. You can also find his work on Android Police and How-To Geek.
Thank you for your message @EA_Darko, though you managed to not answer my question as I was not seeking any assistance at all, nor was any of the commenters in this thread. I'll state my question again:
There are lots of players out there with a Steam Deck (or any Linux machine at all) wanting to play FIFA 23 on this amazing device, and unfortunately, the newly introduced AC system isn't making it any easier.
I have purchased fifa every year since I was a little kid (32) now. I have also always bought the game for all the consoles I owned. Because of this lack of support on EAs part. I am boycotting fifa games from now on.
@EA_Darko I'm sorry, but your statement is incomplete and therefore false. Games like FIFA 22 and Need For Speed are playable on SteamOS, through Proton (if you're unfamiliar with Proton, I recommend reading ). The whole point of this thread is that the anticheat system is not compatible with Proton, while the game itself most likely is.
Just wondering whether anybody has attempted to install and play New
World yet. Apparently it requires Windows 10 and DirectX 12, and at
least with defaults has a pretty heavy graphics load.
New World is using directx 11 and not 12! Even if it says 12 in the specs. But it uses directx 11 and I managed to start and run new world on my m1 macbook air 16GB memory.
The only issue I get is a graphic glitch with the gras on the character screen.
Once I click connect to start playing, it tries to start easy anti cheat which fails to run.
Any clue how or when we get easy anticheat to run with crossover? I think the new world developers have to opt-in to the easy anticheat new proton/wine support. The just have to enable the support for it and I think then it will run.
They added EAC for linux a while back. I've been playing on Linux for a while. Trying to get it running on M1 Mac today and running into the EAC init failure. Wondering how to get the proton EAC runtime to run through crossover? wouldn't that work?
Over the last few years there's been leaps and bounds made in Linux gaming, with continuous improvements being made to compatibility layers and GPU drivers. With over 15,000 Windows games reported working on Linux thanks to Proton[1], things are golden right (or should I say platinum, la Proton's rating system)? Sort of.
There are still some significant hurdles that prevent some of the most popular games being played, one of the more prevalent being anti-cheat technology. With the unveiling of the Steam Deck[2], Valve announced it will be working alongside anti-cheat vendors to get ALL Windows games working on Linux in time for the Steam Deck release[3].
Now after confirming that I am indeed not dreaming (right????), I can't help but feel sceptical. But... why? I don't really know much about the intricacies of anti-cheats, compatibility layers and the hurdles to get this nicely integrated in Linux. So let's embark on a journey to see if we can get any closer to gauging the feasibility of Valve's goals.
Wine Is Not An Emulator AKA WINE is the OG Windows compatibility layer for Linux. To grossly over simplify, WINE allows Linux users to run Windows programs by translating Windows API (WinAPI) calls to POSIX (Linux compatible API) calls on-the-fly[1].
Proton is Valve's fork of WINE[2] focusing on improving this compatibility layer to provide seamless support specifically for Windows games on Linux, as opposed to WINE's more general but config heavier scope. Proton is integrated into Steam directly via Steam Play, allowing you to run games via Proton at the click of a button.
Much like the Autobots and Decepticons, there has been an age-old battle between anti-cheat providers and cheaters. A constant back and forth between bypasses and mitigations, both are constantly evolving and there are different approaches taken by these anti-cheat vendors to tackle cheaters.
It would be out of the scope for this post to detail the different methods employed by anti-cheats but suffice it to say that over the years, the number of mitigations put in place to try and thwart cheaters has stacked up, with ever increasing complexity.
Anti-cheats in many aspects are analogous to anti-virus software, except instead of looking for viruses across a system, they're looking for cheats in a particular game (whether checking game files on disk or the memory used by the game's processes).
This can involve proactive measures such as simple file integrity checks to see if the game files have been tampered with; detecting malicious code being injected into process memory; implementing anti-debugging measures to hamper reverse engineering, all the way to behavioural measures that make use of algorithms, machine learning and other buzzwords to ingest game data and try and determine cheaters similar to how a human could intuitively spot repeated 720 cross-map no-scopes with no need to reload and go that's probably not legit[1].
Earlier we mentioned that Proton works by translating the Windows API calls the program is expecting into calls that the Linux kernel understands. It does this by providing its own version of the user-space WinAPI and libraries (DLLs).
Without diving too much into Computer Science 101, the user-space (lower privileged) applications sometimes need to interact with the kernel (higher privileged) to carry out tasks or get information. Syscalls (system calls) are programmatic, clearly defined ways for a user program to interact with the kernel. E.g. from the man page for open:
By providing its own version of the WinAPI and library DLLs, Proton can implement the same functionality and interface the program expects, but manage the OS interaction using Linux friendly syscalls.
The issue arises when, and is an increasing trend within Windows games, the Windows program calls these syscalls directly, rather than using the WinAPI or libraries. Because Proton only provides the WinAPI and DLLs, those syscalls go directly from the Windows program to the Linux kernel. Yikes!
Last year discussion started making ground on introducing a workaround for this issue into the Linux kernel, with patches introduced by Collabora's Gabriel Krisman Bertazi[2]. Due to the anti-debugging and integrity checking measures we mentioned earlier, it isn't as straight forward as patching the Windows process's syscalls after we load it into memory.
As mentioned in the title to this section, similar but-not-quite-the-same anti-tamper/DRM features (think more anti-piracy than anti-cheat) which are sometimes bundled in by anti-cheat vendors also have a similar impact and were a driving factor in resolving this issue.
At the time, the main option was to use the ptrace() system call to trap on every syscall a usermode application made, at which point Proton could then handle the redirect. Understandably this required a considerable performance hit.
An initial patch involved using seccomp, a Linux kernel feature called secure computing mode. Seccomp also provided a similar ability to intercept syscalls but had the same drawbacks regarding scope. The tl;dr of the patch set was to add some changes to user mode memory mapping and seccomp to allow usermode processes to specify a specific range (i.e just the Windows program being run).
3a8082e126