•      Sign In
• Create Account

# PunCrathod

Member Since 16 Jan 2012
Offline Last Active Today, 12:34 PM

### In Topic: measuring latency

08 January 2014 - 08:14 AM

I know that in order to apply 'smoothin out' algorithm (client side prediction, extrapolation), one has to take into account the latency factor. But it kinda dazzled me as to whom should calculate it and how it is generally measured.

1. Who gets the burden?

-Do the server do the calculation and tell the client overtime?

-Do the client do it (since it is him who needs to be smoothened)

-Do the server and client each has their own pingtime?

2. How would one calculate it?

right now I simply use the simplistic ping approach (e.g., send "ping" message and teh server quickly throw back the reply).

however, it was too simplistic and pingtime was generally change overtime (they sure are very random). Thus the second question. But if we use the average pingtime, it sometimes won't be correct, right? plus if I have to use average pingtime, that means I have to already have several ping results at hand. What if the game has just begun? should I spend my time calculating pingtime first?

3. How was it generally used?

Example scenario:

-client send message that he just pressed "move forward" button. In order to hide latency, he directly moves his avatar forward locally.

-by the time the message reaches the server, however, it's already too late. perhaps by 100 ms. then the server should simulate as if player pressed the button 100 ms ago, thus the server must do "extrapolation" by 100 ms. CMIIW.

-client stopped pressing forward key, thus he sends "stop pressing forward" message to server.

-the server gets the message 100 ms later, oops that means our player is moved too far by 100 ms, so his position must be corrected by 100ms

(pos = pos + vel * -0.1). as such, the server send a position update message to player

-the client received the message, assume it's late by 100 ms. but since this is corrective position, the client simply stick his current position to the server's corrective position. He might also use interpolation (so it looks like sliding over rather than snapping) to alleviate graphical jerkiness.

So am I right on number 3?

4. bonus question. I recently have a chat with some gamedev over IRC, we were discussing minecraft. I threw a question regarding its networking, and some fellow said that the send rate is very low (a particular guy even said that it's only 5 TIMES A SECOND!! WTF!!). that means it sends every 200 ms. now I wonder about its update rate. since minecraft is kinda "physics"-is, I bet they use at least 30 fps update rate. But since I can't get a look at their sources, I can't confirm my curiousity. Do any of you guys know about this? thanks a lot.

Those are my questions, I hope you guys could help this confused guy. Anyway, thanks for your time reading this blocks of text.

1. This depends on where and why do you need it. For smoothing out latency in a fps you propably would calculate latency in the server since it needs to know where each client was when one pressed the trigger to see who got shot.

2. There are a few ways. Easiest being just to measure how long the server or client takes to respond to a simple short message.

3. There are quite a few things you could use the latency for. Movement prediction and correction is perhaps the most common use.

4. Minecraft suprisingly doesn't have that much physics in it. And as far as I know its network update rate depends on the servers tickrate so with a lot of mods it can be as low as once in every 2-10 seconds. The tickrate is capped at 20 meaning it would update 20 times a second at most. But the update rate is not that important in a game like minecraft. A 5hz rate would be more than enough. For example battlefield 3 and 4 updates 10 times a second and its a twitch shooter where life and death depends on a few milliseconds. This is exactly where latency corrections and such come into play to smooth things out.

### In Topic: Advice to lock frame rate

31 December 2013 - 11:37 AM

I think I found the better way, looking at the function SDL_SetVideoMode (which I think doesn't exist in SDL2) I notice a flag that I didn't see before SDL_RENDERER_PRESENTVSYNC , I just add it to my renderer creation function:

renderer = SDL_CreateRenderer(window,-1,SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);

Now the fps is stable 60. (But I wonder if this vsync can be still disable by the user)

This is a bad idea. If your movement rate is based on fps. Enabling vsync will not do what you want. This is because vsync is not quaranteed to be 60hz. It depends on your gpu and display and settings. If you have a 75hz or 120hz display and your gpu supports it and have it enabled then with vsync your game will run at 75fps or 120fps. Or even worse if you are using a 1080i tv as a screen with 30hz progressive setting it will lock the fps to 30. And as you had already guessed users indeed can disable vsync from the driver settings.

You really need to use high preformance timers. Either by forcing updates to 60hz or adjusting movement rate with deltatime.

### In Topic: Is GPU-to-CPU data transfer a performance bottle-neck?

17 December 2013 - 08:05 AM

And do you need to use doubles? Computing your v expression with doubles is slower than with floats (the double division will be really slow) and also converting it to float takes some time.

You don't really need to worry about doubles or floats. As long as your memory bandwith does not run out doubles are almost always as fast as floats on a 64 bit processor as they are both usually calculated with the same alu using the same 80bit registers. Granted with 1 million 3d points you have 3 million doubles and thats about 24 megabytes and there goes your bandwith. If all the data could fit in L3 cache(or L4 if you have it) then you propably would not get much of a difference in performance without using some fancy stuff like SSE(wich can infact process double the amount of floats than doubles in one cycle). But in this case even with SSE you wouldn't get much of an improvement as your bandwith is already holding you back.

Maybe you could sort on GPU and keep the sorted array on GPU and use it as an indirect parameter to your rendering, perhaps as an index buffer. That way, you wouldn't have to stall at all.

This is propably the best bet on getting a million particles sorted inside a reasonable amount of time. Just as a comparison a game that I'm making with a couple of friends has a particle system that has two textures containing the particle data. One for reading and one for writing and swapping them around after rendering. Granted it's only in 2d and no need for sorting but since all the data is kept on vram all the time its blazing fast and we can have 5 million particles without any noticeably decrease in performance(less than 1ms difference in frame time between 100k and 5mil particles with a nvidia gtx 660). And as op said in the first post the shader did the job in less than 1ms too so the best solution would be to figure out a way to avoid transferring all the data between cpu and gpu.

We actually did ours by having three different shaders. One that "rendered" new particles in the particle data texture, one that updated the data between frames and one that rendered them to a framebuffer to be displayed on the screen. So the only data that needed to be sent anywhere was a list of particle emitters active during a frame sent to the first shader and the rest was just a few draw calls. I believe they call this approach ping-ponging. I'm not too familiar with how it works as my two friends do most of the rendering code in our project but I hope this gives you the motivation to try something similar yourself.

However if your particles interact with the rest of the simulation then it gets complicated and I have no idea how to make that happen.

### In Topic: Offset mass angular/linear velocity?

06 December 2013 - 03:25 PM

It seems you are looking for rigid body collisions.

1. This gets complicated real fast. Reading a book on physics is a good start but if you don't want to read a book you can take a look at this http://www.myphysicslab.com/collision.html

Just be avare that there are a lot of vector math and physics related terms and if you are not familiar with them this will propably not help you much.

3. As long as your objects arent bolted down to an axel then yes. Objects always rotate around their center of mass.

4. This one is also a lot of complicated math involving a lot of vectors. The link in #1 mostly covers this if you can read all the scientific terms and know vector math.

Seeing as you are only 14 my advice is to pay close attention in math and physics classes at school. It may sometimes seem boring but when you start to understand all of it and you get your first physics simulation program working it gets fun real fast.

### In Topic: How do I use multithreading?

04 October 2013 - 11:05 AM

Boolean flags aren't atomic (so you have to know details of the platform and ensure there's enough padding that other mutable data won't be too close to the flag), and there's no ordering guarantee that the changed flag won't become visible to the main thread before the star system data is actually committed to RAM (which creates a potential race condition where the main thread sees the flag is true, but reads the star system data before it's been written/completed). As you mention, this then requires memory barriers (both compile-time and run-time varieties) to be inserted after writing to the flag and before reading from the flag (not mentioned above). If you're writing that kind of low-level synchronization code though, you really need to understand why those 4 barriers are required, which is not a suitable beginner task.
Beginners should instead use pre-made synchronization primitives, like critical-sections/mutexes, or a higher level parallelism library.

You don't need to protect the flag. A memory barrier in the generating thread just before setting the flag to true is all that's needed. The data is then quaranteed to exist before main thread sees that the flag is set to true. If you are advanced enough to be thinking about pregenerating the gameworld in advance during runtime then understanding this should not be a problem for you.

I'm not saying you shouldn't study how memory barriers etc work but a background worker thread isn't that complicated. I just think its arrogant to claim someone can't possibly comprehend multithreading at all if he hasn't been programmin for 10 years and hasn't learned the inner workings of whatever platform they are targeting. Where I studied programmin a few years back background worker threads were considered beginner stuff.

PARTNERS