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

This is something which irks me.

All major engines (Unity, Unreal and even Godot) provide 2 different mechanisms for callbacks in your scripts: A callback before each rendered frame and a callback before each physic step (Update() and FixedUpdate() in Unity).

Now, physics always run in a fixed time step. Usually 60 times per second. If you move your player, the game will always need to wait for the next physic callback to move the entity around. Same for spawning projectiles and or checking hitscan weapons with raycasts. You always need to wait.

In this case, when V-Sync is on an your screen updates at 60Hz per second everything is fine. But on a screen with 144Hz, there is inevitable input lag.

Can someone tell me, how on earth can this be improved by disabling V-Sync? It's basically not possible to reduce input lag in this scenario.

I know there are ways to hide the lag through Input Prediction and Entity Interpolation, but those are necessary band-aids for multiplayer games, where you accept lag which is already an order of a magnitude larger than local input lag. And for single-player games? If you introduce physics your oh-so-nice 1000 Frames per Seconds are basically useless. But please tell me, if I missed something.



The controller function in unreal is separate to the physics engine. Raycasts and spawning do not need to wait for a new physics tick to do their thing.

Interp and extrapolation do not delay your input. Interp fills in lag time with predicted movement for other player characters to hide 50ms+ of lag from the player. Your client side input still exists and is updated client side in realtime. It may get corrected by lag after the fact. Your input is not delayed to match their lag.


Network lag is not an order of magnitude larger than local input lag.

E.g. Dota 2 and CSGO servers in Europe have <40ms ping for most people. Local lag should be up to some 16ms from a 60Hz display plus 1ms from a 1000Hz mouse/keyboard, half of that on average. If the hardware is bad, it could easily be some extra 30ms from the display and maybe 16ms from the mouse/keyboard -- think 125Hz poll rate and bad debounce implementation.




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

Search: