Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 01 Oct 2011
Offline Last Active Nov 23 2012 05:48 PM

Posts I've Made

In Topic: Authoritative Server-side Input

22 November 2012 - 03:44 PM

EDIT: Issue solved! Thanks for all the help!

In Topic: Authoritative Server-side Input

20 November 2012 - 04:59 PM

This may be similar to a problem that I had encountered. I noticed that when remote testing over the internet, local clients were working correctly, however the remote players were experiencing large prediction errors. It became evident that a factor was affecting the simulation. For me, I wasn't easily able to "rewind" physics simulations. For example, prior to becoming aware of the bug, I was simulating inputs in real time as they were received. The problem here is that the upstream latency will shift the inputs on server and client. The client stores them immediately as the current tick, whereas the server may receive and store them several later, resulting in a discrepancy. For me, as I don't have full exposure of the physics system, fixing this involves forward predicting when the inputs will be received by the server, on the client. So that If the upstream latency is 5 game ticks, the client predicts the results of those inputs and stores them on the current tick + latency (5 ticks). For you, as you're working in C++, one can presume that you've more control over the physics steps, you'd send the intended tick number with the input packet, and the server would "rewind" to that state, and simulate for the time step. This would account for any latency.

Sorry for this late reply!
It mostly works now, except I get some floating-point issues. In order to make my server frame-rate agnostic, the client sends the "simulation time", which is basically the time that the client used to multiply the movement velocity (V*t) to the server. The server then subtracts 0.166667 from this value each frame (the server runs at 60 FPS) or the remaining value if it is less that 0.166667. Unfortunately, this causes some small floating point precision errors. Add in packet drops (if packet #2 was dropped, when I receive packet #3 i just process #2 with the information from packet #1 and then process packet #3), and the client will slowly become inaccurate.

Is there something I'm doing wrong here? Is it necessary for the client to also send its predicted position, and have the server decide whether the error is ok, and then reset its position to the client's position? Or should the server just be the absolute decider?

Each of my input packets is currently 10 bytes and 5 bits, and adding the predicted position would cause it to be 22 bytes and 5 bits, effectively doubling the original size.
Just for movement, I'd be sending out 5.4kbits/second.


In Topic: Authoritative Server-side Input

30 October 2012 - 02:21 PM

Hmm, I am sorry but I am not really getting your implementation.
Are you receiving the position from the client and assuming it is right?
Also, how are you calculating the position? Are you calculating the position assuming the client has a set FPS?

I believe you should be using a time difference approach, this way the FPS would not affect the math at all. I always use something like this:

nextX = currentPos.fX + (cos(angle) * moveSpeed * timeElapsed);
nextY = currentPos.fY + (sin(angle) * moveSpeed * timeElapsed);

This way, assuming the latency is nearly constant, the amount of time you move should nearly the same and you will be in about the same position (a small error is OK).

Hi, Knolan, thanks for the reply!

For input, the server sends only the keyboard state to the server.
On the client, I multiply the movement vector by the time elapsed since the last frame, and do the same on the server.
Unfortunately, this is where I think the error comes in; the timing on the server and the client may not be exact, and therefore this causes a discrepancy.

In Topic: Rendering Edge on 3D Quad

10 May 2012 - 12:23 AM

I'm quite sure in Minecraft it isn't a textured quad but a 3D model.
And I cannot think of any way how to "fake" those sides in DX9 (XNA) without actually having them in the model - but that doesn't mean such a way doesn't exist ;)

There are 2 ways to achieve this:
-create a mesh for every weapon
-make a voxelsystem:
I think in minecraft the texture is getting voxelized(is this a word?^^)

I can´t think of any other possible way...

I took a look in MCP a bit, and it appears that Notch draws quads with a "cross-hatching method". By that, I mean I think he draws 16 horizontal and 16 vertical quads, and that allows for the thickness.