Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nightcracker]

I agree with Orpheon here.

[Orpheon]

I agree with Orpheon here.

*Marks this in the historical PyGG2 chronicles.*

[nightcracker]

I agree with Orpheon here.

*Marks this in the historical PyGG2 chronicles.*

I was just going to edit my post saying "call the newspapers"  .

[NAGN]

uh yeah

you know what fuck pygrafix; today I'm going to rework the font system so we can eliminate that dependency all together just so I don't have to compile it on my ubuntu laptop

[Orpheon]

uh yeah

you know what fuck pygrafix; today I'm going to rework the font system so we can eliminate that dependency all together just so I don't have to compile it on my ubuntu laptop

^ Pro problem solving.

[NAGN]

okay.

1. it runs twice as fast
2. it has interpolation and lag compensention
3. right now it has some stuttering issues. Also there's a lot of bugs in the library we're using

we probably wouldn't be able to get a stable release until after pysfml/sfml 2 has stabilized

[Orpheon]

okay.

1. it runs twice as fast
2. it has interpolation and lag compensention
3. right now it has some stuttering issues. Also there's a lot of bugs in the library we're using

we probably wouldn't be able to get a stable release until after pysfml/sfml 2 has stabilized

Ah damn. I was hoping it would be more stable than pygrafix. Whatever, at least it's being developed, contrarily to pygrafix.

Also yeah, those stuttering issues are starting to bother me seriously, I'll try to track the cause down.

[Orpheon]

I've got good news and bad news:

Good news is, I fixed some small bugs in networking which made it a touch smoother (the time variable of the states wasn't even updated at all :/) and also found out the cause of that jittery jumping.
It's because the client is nearly on par with server, time-wise. So this happens:

State 44: Client jumps and sends jump, as well as raising vertical speed by a huge amount. Server doesn't know of the jump and says that no-one jumped in state 44.
State 45: Client continues to jump. Server still doesn't know of the jump and says that no-one is jumping in state 45 either.
State 46: Nothing interesting.
State 47: Client gets the server message for state 45, takes it as truth and discards the jump (therefore teleporting back). Server gets client message for states 44 and 45, and makes the client jump.
State 48: Nothing interesting.
State 49: Client gets the server message for state 47, and jumps again.

Since this happens in a fraction of a second, it's noticed as a sort of short wobble in the air before suddenly shooting up by the user.


The bad news is that I have no idea how to fix it without lag compensation (which we agreed we don't want) or major hackery. One alternative would be to make jumping an event, but even that I'm not sure how it would help.
Meh.

[Phantom Brave]

this is why your "rewrite client history" networking solution is a horrible idea compared to classical interpolation (which your arguments against are trivial when you add input prediction)
the only lag compensation that will solve this problem is the client telling the server exactly what to do, and nobody wants that anywhere.

[Orpheon]

this is why your "rewrite client history" networking solution is a horrible idea compared to classical interpolation (which your arguments against are trivial when you add input prediction)
the only lag compensation that will solve this problem is the client telling the server exactly what to do, and nobody wants that anywhere.

My "rewrite client history" networking solution is standard extrapolation and has been used in literally every big FPS game since Quake 3.

[NAGN]

Wareya I'm pretty sure that we do the same thing as the half life 1 docs except that we have the client store everything (which is stupid and broken, but I won't get into that)

Orpheon the server must never be "on-par" (ahead) of the client, and I'm not so sure how this could be possible, judging from my previous knowledge of the half life 1 interpolation (book of hook quake 3 seems to be down, so idk)

How can the server determine that the client has not jumped in state 44 without acking the packet first? iirc the server probably shouldn't be interpolating states ahead of the client

[Orpheon]

Wareya I'm pretty sure that we do the same thing as the half life 1 docs except that we have the client store everything (which is stupid and broken, but I won't get into that)

Orpheon the server must never be "on-par" (ahead) of the client, and I'm not so sure how this could be possible, judging from my previous knowledge of the half life 1 interpolation (book of hook quake 3 seems to be down, so idk)

How can the server determine that the client has not jumped in state 44 without acking the packet first? iirc the server probably shouldn't be interpolating states ahead of the client

The book of hook article: http://nclabs.org/articles/5 (I asked NC to saveguard and host it again)
And no, you don't get it. The ideal thing is that the client and the server are exactly at the same time and state. The server isn't interpolating anything.
As for that with the client storing everything, yeah, we discussed that already.

[ajf]

NOW TO IMPLEMENT HP!

[Phantom Brave]

orpheon, there is no magical bullet to remove server/client latency discrepancy and never will be. Nagn brought up a completely valid point and you just tossed it away. The server can't know that the client jumps until the input gets to the server, at that point the client will already have confirmed past states without the jump, and you can't get around this without letting the client tell the server precisely what to do with the character, not to mention that the simulation "fast forward" lag compensation method is totally prone to constant subtle desync. This is just an extreme case of it.

[ajf]

Not read much of the rest of the thread, but Wareya's right.

It's not about true synchronisation. It's about providing a close approximation, or, faking it entirely. Video games are not about true accuracy, they're about fun and about giving the illusion of reality. Fake it until you make it. This applies to graphical effects (particle generators anyone?), AI, sound, physics, environments, et cetera. And it also applies to networking. You can only hope to be close to synchronisation, and do some tricks to make it appear in sync. But you cannot remove lag, and you cannot truly sync clients.