Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The real issue here is that it was a detectable optimization, Nvidia may play similar tricks except it’s not an issue if the code is embedded deeper into the hardware stack.

For example, Nvidia cards are great for cheaters because you can disable flashbangs and smoke grenades using the stock driver.

If we push it that way, any improvement of FPS due to hardware could even be considered unfair, and to ensure fairness, everybody could theoretically be limited to 30 FPS and xxHz refresh rates.



Reflex requires the game developers to use the Reflex interface via NVAPI, the AMD global anti lag feature was hijacking calls at runtime and modifying the memory of running processes.

I don’t know how this design passed basic red teaming during the design phase not to mention QA.


What actually happened is that the game code was modified in memory which VAC disallows because that's how many cheats are implemented. I'm not even sure what you're trying to say. Yes you can disable some effects in games through changing driver options and you can make your monitor render a red dot and add macros to your keyboard, those all are a distinct problem from the subject here.

A framerate limitation for "fairness" wouldn't make sense because you'd basically be arguing that it's unfair that someone saw one single extra frame that some player zipped across the screen and they were able to track them whereas they wouldn't without that extra frame.

But a game being networked naturally presents the same issue and it can't be solved (in an engine like source or unreal): player locations are sent to your client at a fixed sample rate. Whether you see a player zip across the screen will just be determined by a bunch of phases of cyclic phenomena: for instance your client renders every 33.33ms (for 30FPS) and the server says he's at position A, then the server says he's at position B which is in your view, but your game isn't rendering yet because it just finished rendering the previous frame. Then you get a packet saying he's at position C which is also off your screen and now finally the rendering happens, rendering another frame with the player off your screen. So you never saw him cross your screen. But another player sitting right behind you looking in the exact same direction will be on a different phase of his render loop: he may render right after receiving position B and so he will see the player zip across. This example ignores interpolation and stuff but it will still apply even then.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: