Here’s a video of the stuttering issue. Only thing I’m doing is pressing 4 to set velocity, then center screen around the green dot and zoom in quite a bit. After 16s+ I’m not doing anything.
1 Like
I added the server position rendering, made the grid relative and added a switch for the constant change, no changes to any significant code. We are not talking about the same stuttering, the stuttering I was testing was produced when leaving everything as it is on startup and then just changing the latency to 1000ms and back to 0ms a few times, that get’s fixed with the min/max change.
1 Like
So far it looks like Lomsor’s changes might work, but I need to analyze it in depth. The stuttering seems to be gone ( the one I’m interested in ), and it still reacts to changes in latencies.
@Lomsor The client always sees networked actors in the past. But moves the local player instantly. That’s client-side prediction. All games do that. I would recommend to read Valve’s article about networking which is the standard in the industry:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
And especially the parts about interpolation and input prediction.
It sounds like JB47394 is trying to do extrapolation at all times, to avoid interpolating in the past. While it’s true that it might better match the actor positions to where they currently are on the server, it introduces a lot of other problems ( especially: if you move into a wall, you’ll see the actor sink inside the wall. It’s especially an issue with lower snapshot rates ). AFAIR it’s how the ICP was doing it, and I went away from this approach because of these problems. Basically, on the client it can show the actor to be in a position it’s not / never been to on the server.
2 Likes
this happens to some degree even when not setting the velocity to 4, you can see it if you zoom close enough
1 Like
Yeah, hence why it’s dependent on absolute velocities, which is a pain. Even if you get ride of stuttering a 5 Km/sec, if you test at 50 Km/s, 500 Km/s etc…you might have surprises.
@Lomsor If you increase the snapshots rate ( ex.: snapRate = 1.0 / 30.0 ) you get back the stuttering, and it’s even worse than the original.
That’s alright. What I was mentioning is, that when you change display time you are effectively making time move slower or even backwards. Currently this only effects remote players.
This means that when flying in formation and you lag out. The time smoothing in its current form will make you break formation. This doesn’t need to happen.
I’ll look into that article. Thanks.
This also happens in the original. Can’t really tell if more or less. It also happens with time smoothing off.
At some rates it happens, in other it does not.
Also changing snapRate kinda breaks my solution as its “tuned” to a certain snap rate. As said, workaround. It’s a very simple regulatory code. It also breaks if extrapolation only happens only every now and then …
Will look some more into it if I have some time.
3 Likes
Well the game has a variable snap rate. Distant, slower objects have lower rate than fast, closer objects. So the solution should work with any snap rate, from 1 sps to 30+ sps.
Thanks for the link to the Valve article. It explains how the lagging ship position is compensated when doing things like shooting. The server just says
“The client fired, but his shot was based on his 100ms-old view of the game world. I’ll go back 100ms and see where his shot landed.”
In theory, that works even for 5km/s engagements because the server has an accurate history of world state. According to the Valve article, the server keeps a cache of 1000ms of game state.
Note that the formation flying problem remains. If we want to fly in formation at 5km/s, we’re each going to see the other’s position 100ms in the past. While we can shoot at each other because the server corrects for positions, it can’t do anything about what we see. So if we’re both next to each other on the server, we’ll both see the other ship 500m behind. So we’ll both slow in an attempt to match positions.
In human FPS games, ‘formation running’ isn’t common practice. But if it was, the sub-10m/s speeds would introduce about 1m of visible position offset. That’s more than a body width, but it pales in comparison to the 10 ship lengths that Battlescape would see just for the 5km/s case.
And this takes me back to islands/bubbles to drop the velocities in the prediction code to near-zero. Note that I have some doubts about how it would work without the full warp prototype treatment. It was designed for a specific environment, and employing just a piece of it may or may not work out.
I’ll close with the comment that the warp prototype never implemented client side prediction. Everyone just worked from the server data as it arrived. Nobody said a word about client control performance. I wonder if positions can discard client side prediction, with only orientation being client-predicted. It’s a newtonian environment, after all. Ships are subject to the dictates of physics.
Yep. To avoid showing ships in their past locations. The technique can certainly throw the other ships around quite a bit when the lag gets particularly bad. I figured that having a reasonably accurate current location was better than the alternative.
So the only way to make formation flight possible at high speeds is to either extrapolate the positions of the other players all the time or have your own ship fly in the past aswell.
- Own ship flies in the past like the other players
- Other players positions are always extrapolated
- Own ships flies in the present, other players fly in the past
0 voters
1 Like
I think it all depends on the end result.
If the end result of extrapolating all the time during high speeds delivers a better end result and experience, then why not.
I think when traveling at high speeds the assumption that the ship continues to travel at that high speed seems logical, if this results in inaccuracies that can’t be well hidden when the speed or direction is suddenly changed that would be bad, but is it worse than the stuttering and time delay?
I think that “own ship flies in the past” is not really an option, because that would result in a input delay which would probably make the game unplayable.
Another option would be to interpolate to a past position when altering the time and then continue “life”.
This would have the benefit of allwing for formation flight even with high jitter players and won’t introduce any lag, except some for the high jitter players.
–double post
Having one’s own ship ‘fly in the past’ means ones inputs happen in the future. This means input feels laggy.
This technique is used in RTS where it’s not noticeable but in FPS it’s an issue.
1 Like
Having your ship ‘fly in the past’ means that there would be no observable client-side prediction. This means that if your ping to the server is 100ms, then your ship would respond to your control inputs with a 100ms delay. Valve came up with their approach because that sort of delay is not acceptable in their games, but Battlescape might get away with it because of the use of newtonian physics. It would be an interesting test to try - if it didn’t require a lot of work to assemble. Ideally, without telling anyone about it. Confirmation bias and all that.
Interestingly, the clients would still have to perform prediction because they need to do the physics simulation. They need to know in advance that they hit a mountain. They then tell the server before it actually happens so that the server can work it into its next update to everyone.
Do any of the games you’re thinking of involve Newtonian physics?
The stuttering can be solved. It’s only the time delay that’s a possible issue.
Aaaaand I voted for the wrong item. Move one vote from “extrapolated” to “all in the past”.
1 Like
I changed my vote. JB47394 argumentation is solid. Having your own ship fly in the past (only during highspeeds) would be the better way to accomplish Formation flight. The input lag would not be that bad because combat isn’t happening anyway and having sluggish controls while flying high speeds seems reasonable and can be explained away by the nature of fast travel.
Thats kind of off topic since this apparantly has nothing to do with the stutter but I think it is worth discussing anyway.
The switch to display ones own ship ‘in the past’ could happen when activating the warp drive.
I’m the only network programmer, there’s no way we can do such elaborate implementations as having different systems for low speeds vs high speeds. Unless we want it to continue as a R&D project for many months.
As for removing client side prediction and having the player controlled ship also be displayed in the past like other entities, I’ve already tried that. As expected it’s working well when the latencies are low and become unacceptable at higher ( > 150 ms ) latencies. And it’s even more true with a ship such as the interceptor in boost mode. Now if we only had the corvette without boost, it’d probably work quite well even at high latencies… but unfortunately that’s not the case.
3 Likes
Activating the warp drive could act as a switch between the current implementation and switching to displaying everything in the past like you already tested as mentioned. Would that be difficult to implement? I think that could be a possible simple solution since handling the interceptor at high speeds (in warp) is just as sluggish or more than the corvette at low speeds.
The time difference could even be so high that the input delay is the same even with very low or higher latencies, to make sure that the sluggishness is the same regardless of latency. To counteract that delay you could make the handling more responsive during high speeds compared to the handling in the current pre alpha version.
So the warp drive would act as a switch between the current and the ‘alway long in the past’ way of displaying the world.
Maybe we really have to accept the fact that we can only avoid stuttering to a certain degree but after that we can’t avoid that (e.g. scenarios were battles wouldn’t happen anyways)
It is an engineering implementation problem.
So I invested some more hours.
You can see the result here:
http://lomsor.com/inovae/InterpolationTest/InterpolationTest_Lomsor_8.zip
I tried to fix the stuttering that is disconnected from the timesmoothing. Try setting snapRate to 1/30. You’ll see it in the unmodified version.
I was not able to eliminate the stutter. It appears its due to the interpolation being executed at differing intervals.
I tried to fixate the intervals but broke something in the process. So I reverted and tried to make the interpolation work with any interval.
I think a further step would be to use a function similar to lerpdp there. One that was optimized for fixed “f”. We know how long it will interpolate for. That needs to flow into the formula.
This is a different case from the timesmoothing interpolation that has its current value as the start point of the interpolation.
I was not able to fix the stuttering due to positional interpolation. I guess the reason it works with the default settings is that they align up perfectly.
I tried some more stuff in there. Also worked on improving timesmoothing. Broke something in the process though. welp.
1 Like
Lomsor, you’ve got things smoothed out, but I’d very much like to see the actual server position as well.
What becomes unacceptable? The perceptible delay in control of the ship?
1 Like
A quick last one for today, maybe someone can check, this seems to fix the stutter, maybe I’m just tired.
double delta = Math.Pow(Math.Abs(displayTime - targetTime), 4);
3 Likes