7 ms·
Most likely, this is similar to NVIDIA reflex. In that case, they simply wait in the engine loop directly before mouse and keyboard entry are handled. That way,
by fxtentacle 3y ago
Most likely, this is similar to NVIDIA reflex. In that case, they simply wait in the engine loop directly before mouse and keyboard entry are handled. That way, the GPU can process this new data immediately (as opposed to first waiting for vsync) and thereby overall latency is reduced.
- noduerme 3y agoWhy would this be considered an illegal cheat? In a networked game, shouldn't the only determinative factor be whose input arrives at the server first?
- tremon 3y agoMy guess: this changes the timing profile of the overall game/engine. If the engine monitors itself for erratic/unexpected delays, it may conclude that it's running under a debugger if certain procedures take far longer (or shorter) than they should.
- serf 3y ago'weird' i/o hooks and erratic timing are big red flags for anti-cheats.
- SXX 3y agoIn this particular case anything hooking itself into game code is considered cheating.
- noduerme 3y agoAh, so it's considered a "bot" because the game is expecting something to reach the display before a human responded? The card isn't doing any network input, so something must be checking if the state was blitted before the human response...(?!)
- diath 3y agoIt's considered a "bot" because it injects its own code into the game itself, which is what cheats do.
- SXX 3y agoIt's not considered bot or anything. It's just Valve forbids any software signed or unsigned to mess with game executable, data or memory without being specifically whitelisted. Why? Because even if software doing this is legitimate it's can still be used by actual cheaters by patching it.
- Waterluvian 3y agoIt’s a nice clear line in the sand. The program is a black box. Do not inspect or augment it.
- deleted 3y ago[deleted]
- sa-code 3y agoWall hacks are also a type of cheating that doesn't require changing your communication to the server
- mort96 3y agoThe server doesn't always decide. It's common for shooters to want to guarantee that if it looks like you shot the other player on your screen, the game will react as if you shot the other player, even if the server would have considered it a miss due to timing differences. Those things can really only be done by trusting the client not to lie, which means verifying that the client hasn't been tampered with. Plus, there's a lot of cases where the server sends some pieces of information to the client but the user isn't supposed to see it. The locations of the other players is a common example, where people modify their client to render outlines of players through walls. That's a huge advantage but doesn't even affect anything hit registration related.
- Wowfunhappy 3y agoThis makes me wonder—how much performance would you loose by taking a "distrusted client" approach, and only sending data that you want the player to know about? Could you make cheating basically impossible?
- davikr 3y agoValorant and Counter-Strike attempt to do this as much as they can, not sending information about enemies the player shouldn't be able to see. This is not flawless, though, probably due to performance or latency requirements. Iirc, Warzone also sends information about non-existing players to suspected cheaters to attempt detecting aimbots.
- snailmailman 3y agoI think the client also receives information about non-visible-but-nearby players for things like footstep noises. In counter strike you can hear a person around the corner running around, reloading, etc. and I think in some cases you can shoot through thin walls at these players. Even if they are completely obscured from view.
- filoleg 3y ago
- dbttdft 3y agoThey are being banned for the game code being modified in memory, the anti cheat knows nothing about the fact that input latency was decreased. And no, reducing input latency is not considered a cheat, anywhere, no game does that.
- hypercube33 3y agoYep exactly. It does remind me of the story of someone coming to quake con in the 90s though and using a "feature" of idtech game engines where it tied a lot of code to frame rate and thus once you get enough fps, time accelerated effectively for that player. I think it was ruled not a cheat for that season (I could be wrong it's been over 20 years) but discouraged for future years.
- jfim 3y agoNot sure if that's what you're referring to, but quake 3 physics behaved differently based on the client frame rate. 125Hz made all of the physics steps round up when jumping, allowing for just a little extra height that allowed for some jumps.
- sillysaurusx 3y agoThat seems like something any engine programmer would implement on their own. Could it really be so simple? I guess if NVIDIA does it, then it must help. How odd.
- armada651 3y agoNvidia reflex works by inserting a wait before input processing that dynamically adjusts so that the frame completes rendering right before the monitor's v-blank. Thereby reducing the amount of time the completed frame sits idle in the backbuffer, which in turn reduces the delta between when input is sampled and when the frame is displayed. To do this effectively is very difficult without a complete view of the pipeline all the way to the display. That is why a feature like that works best when the driver and game engine work together rather than either side attempting to implement it unilaterally. It seems that AMD attempted to implement this feature without help from the game developer by hooking the Windows input APIs directly.
- deely3 3y agoWait, how does exactly this work? As I understand it works something like this: mouse/keyboard input -> driver -> game engine -> graphic engine -> GPU. So, what exactly NVIDIA reflex (and Radeon lag+) did? How does intercepting commands in game engine helps the performance of GPU? Upd: I did read explanation of Nvidia reflex (NVIDIA Reflex keeps the CPU perfectly in sync with the GPU to eliminate the render queue.) and still not sure that I understand. Why developers of game did not implemented this fix themselves?
- armada651 3y agoThe first step to reducing input latency is to eliminate the frame queue. Usually the driver allows the CPU to submit up to 3 frames worth of rendering commands, which means that on a 60Hz monitor the image being displayed could represent input from up to 45ms ago because of the frame queue. The frame queue exists to eliminate GPU bubbles where the GPU sits idle waiting for the CPU to send new rendering commands. If the game developer puts in the work of eliminating these GPU bubbles as much as possible then it's possible to turn off the frame queue while maintaining a good frame rate. This step of reducing latency does not require intercepting any calls and is probably what is being done in AMD Anti-Lag. However there is a further step to reducing input latency that AMD called Anti-Lag+ that does require extra hooks in the engine. I explained that in this comment: https://news.ycombinator.com/item?id=37879517 https://news.ycombinator.com/item?id=37879517
- Waterluvian 3y agoAre you describing triple buffering? Competitive gamers generally know to leave that off in the settings.
- armada651 3y agoTriple buffering maintains a queue* of fully rendered frames ready to be displayed by the monitor. What I'm talking about is a queue of rendering commands for frames that still need to be rendered by the GPU. * triple buffering does not actually use a queue, but rather two buffer swaps, which means a frame is allowed to skip ahead if completed early.