Hey that’s one of these time where I’m surprise the direction the discussiopn goes … I EXPECTED people say "nothing new, it’s DEAD RECKONING EXTRAPOLATION, ie a quite old method some action game already used, ESPECIALLY over the internet.
Having followed and being aware of many research on the area, he is right, the player who benefit the most are casual and noob, pro do better but can compensate even low fps even at competitive level.
They did a previous video without sponsor, but nvidia seen that as an opportunities, so they redid a bigger test that became that video, result is mostly the same, which mean nvidia is only cashing on something already given, also it match research in similar domain.
The difference is that dead reckoning extrapolation is common in netcode, and Arowx seems to actually be talking about local player input prediction. In netcode, dead reckoning extrapolation tries to predict locations of other players based on last known location and movement vector. The netcode solution works well in many games, especially if their is a decent system in place to smoothly correct any mispredictions.
By contrast, local player input prediction would try to predict the player’s next inputs and try to react to those inputs before the inputs were received. I doubt there is a solid way to smoothly correct mispredictions in local player input prediction. For example, if I move my mouse left and the local player input prediction thought I was going to move the mouse right, then it would feel pretty jarring to watch the camera turn to the right.
Yeah, that was my thought, too. As an example, Rigidbody already has two smoothing modes, one of which relies on extrapolating future expected positions of objects. The purpose is different, but the approach is the same.
This breaks casuallity, you can’t control the present from the future of the same timeline.
i think it will just make stuff jump more when trying to reconcile the input with the simulation.
[quote=JoNax97, post: 6030290,
member: 1050258]
Your premise is flawed. It’s people who are competitive who invest in the hardware necessary to reduce frame time.
So you can argue that performant players buy the pro hardware and not the other way around.
[/quote]
Every time your cycling through your frame you are updating inputs and working out where the player has moved from the last frame to the where they will be in the next frame.
In theory if the refresh rate was 16 ms and the input ran at 1000 hz or 1ms intervals there could be 16 new inputs most of which you will have to buffer until the next frame.
Even with normal inputs the player could send input signals that occur within the frame time window but after the time that inputs are calculated so they will not be read until next frame.
If we adopted output lag compensation we would change the above code to this.
player.position += movement * speed * (deltaTime + outputLagOffset);
And if our input system could capture not just the input but the exact time it occurred then we can add negative time inputs to the next frame.
Or better still inputs could be running at 1000 hz in their own input loop and the rendering loop would just get the latest set for the next frame.
Nah it’s done by so many offline game too, mario 64 do it, when you input a direction, it look forward, sample 4 steps, then resolve, coyote time is another similar idea example, you sample future position in empty space, but only resolve a few millisecond behind, so you allow the player to walk, motion matching do many step in the future to blend in the present, etc …
Additionally in single player games one can think of the game preparing not current frame, but the next one. Meaning, it is already calculating future values, whatever is on screen is current frame, and delay is player input lag.
You have causality backwards here. People who play more games are likely to be better performers, and are likely to spend more money on gaming systems.
A proper analysis would require the same players playing on different systems, and measuring how their performance changes as they switch systems.
I note none of these curves start at zero. Which suggests that the differences are mostly in baseline measurements, rather than actual performance.
This is possible to do, but would only resolve part of the latency problem. The 60Hz display rate is the bottleneck of the system you described. Even if the program updates the game world as fast as possible when the program receives the input signal (which only reduces the processing latency), the user could not perceive the update it until the feedback (in this case, updated display content) is provided.
Help me understand why knowing the timestamp of the input event would eliminate the input latency?
Without specialist hardware to test and time your devices input lag (mouse/usb hub/motherboard/cpu/drivers/bios/os) you have no idea how long it takes.
Also tests show that input latency can vary significantly over time so having an average device offset might be good but may not be accurate across hardware/software combinations/versions.
With time synchronised input devices they could send you the exact millisecond in time the event happened then the game/app or OS can offset the output to compensate and provide a virtual zero lag experience.
Video showing various mouse input latency on CS:GO running at 240 hz
I don’t think this is the device input event time, it is more likely the system input event time, therefore I’m guessing this information will not compensate for input lag, but should help with input frame lag.
Although it looks flexible enough to allow a device developer to add it as a feature.
There is an option to poll a device for information so if you timed this request/response as a kind of ping a number of times (with a low level API) it should provide a decent input lag time.
But the event still takes time to reach your program, even if you could guarantee the timestamp is generated in reference to a universal timeline (like a global clock). You could use that latency info to offset some information based on time (like player’s next position in a movement), but for any other things that does not care about time you still suffer from the event arriving late, like whether the player should be moving.
A similar situation to your game input latency situation is Bluetooth audio. In that world, there are already ways to get latency info and manufacturers on all ends have adopted it, so a video player could sync graphics on the phone screen with the audio via a bluetooth headset. The problem is that because latency exists, the audio has to start playing ahead of graphics, so the either the player skips the first dozen milliseconds of the audio or the graphics does not begin until the audio is played with a head start. If the viewer wants to pause at an instance, the audio and video cannot, and can never stop together. You are basically trying to sync your game world with the player’s input. As long as there is latency, you receive the information late, later than your intention.
Notice how that example is different from your idea so far, because it includes the player input (mouse input)? Everybody agrees that games benefit from reducing each latency. But your idea in this thread is basically to try to react to the player before the player does it, and that won’t work to actually reduce latency. You cannot simply roll the time forward to get around latency, unless you can successfully implement a local player input prediction solution that correctly predicts player input every frame.
Arowx, this thread is suffering from the same problem that most of your other threads suffer from. You have an idea. You post a bunch links, videos, and images to build hype. But you don’t discuss the actual problem with your idea. In this thread, the actual problem is you cannot successfully build a rock solid local player input prediction system. Without a local player input prediction system, you cannot roll the time forward like you are advocating. Feel free to completely ignore this basic fact and post more unrelated images and videos, though.
I am gonna have to agree here, we aren’t really talking about any solutions (or really even a clear problem), it is just sort of fantasy speculation over non-existent tech. That is not what this forum is for. It is interesting to talk theory about game design (the correct forum), but talking theory about hardware is off-topic. No one here is developing hardware or writing game-engines. Try reddit or /. for hypothetical hardware/application stuff. If you have a working prototype/application of what you share that runs in Unity, that might be valuable discussion, but not this. Ending.
