To clarify, this does not seem to only affect cs2. Antilag+ has been slowly enabled on a game per game basis, and they recently started adding multiplayer games. They seem to also be affected.
AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was. Even if we assume they were aiming to be whitelisted (I'm not sure hooking into game engine code is even common, apparently it isn't), they have still pushed the updates before the whitelisting happened. What was the plan here?
There are open source projects attempting a similar approach to antilag+ ("patching" the DLLs at runtime) but they all seem to warn you about possible anticheat detection on multiplayer games. Again, this was patching the actual engine DLL, not the rendering or graphics related DLLs that drivers sometimes have to patch for specific games.
> AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was
Hasn’t it been true for ages that GPU drivers contain fixes for a lot of GPU instructions from popular games that would otherwise be broken.
In that case, if they are used to fixing games already, it might not seem a big step from their side when they decided to also patch game code that runs on the CPU. It was unfortunate that they did not realise this would lead to triggering anti-cheat systems in games though.
But there is history of others altering program code too. For example Microsoft Windows included code specific to various pieces of software that would otherwise be broken. I wonder if that ever lead to trigger anti-cheat systems in any games.
>> it might not seem a big step from their side when they decided to also patch game code that runs on the CPU. It was unfortunate that they did not realise this would lead to triggering anti-cheat systems in games though.
Never mind anti-cheat systems. This is a huge boundary violation - like when Sony installed root kits. It's one thing to modify your own products behavior, but quite another to modify other software!
I believe all AAA companies work very closely together with the GPU vendors during all the cycle of dev.. it isn’t as if they aren’t aware or don’t want it
From my understanding they continue to patch even when the developer has abandoned the title. iD doesn’t care if Doom won’t run on a new graphics card, but the consumer will so it’s in GPU maker’s problem, not the developers (they already have your money).
It’s a different layer for those though. In each of those other cases, the code paths that diverge per app are not within the app libraries but within the system SDK or the graphics driver.
Those are layers the application has to trust , and also has expectations may change implementations. They’re only accessible as an API.
In this case they were stepping into code they don’t control which is a huge violation of trust
https://www.reddit.com/r/Amd/comments/177bdfg/amds_antilag_a...
You can also see this pretty telling forum thread:
https://answers.ea.com/t5/Technical-Issues/Account-Falsely-B...
AMD also openly said that they are patching game engine code, which is just bizarre. Not sure what the thought process was. Even if we assume they were aiming to be whitelisted (I'm not sure hooking into game engine code is even common, apparently it isn't), they have still pushed the updates before the whitelisting happened. What was the plan here?
There are open source projects attempting a similar approach to antilag+ ("patching" the DLLs at runtime) but they all seem to warn you about possible anticheat detection on multiplayer games. Again, this was patching the actual engine DLL, not the rendering or graphics related DLLs that drivers sometimes have to patch for specific games.