Sign in to follow this  

Unity Latency vs Speed: Multithreading or single-threading

This topic is 4863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently working on the core design of my game engine, deciding how the components will fit together. My current concerns are keeping input latency low, and making sure video v-sync doesn't stall the gamestate updates. After reading through these forums and other articles over the past week, I've been toying with two ideas: IDEA 1 (from this thread) Use a single thread, and attempt to run the game state (including input) at a fixed rate, while allowing the renderer to run at full speed. Essentially the game loop runs as fast as possible, and within each iteration the time is checked to determine if the game state should be updated, which could be set to around 20 times a second. PROBLEM As nice and simple as this method is, I see two big problems. First, input latency. Polling for player input only 20 times a second isn't going to feel very smooth to the player, it will react rather choppy. And Second, the speed of the loop could stall if v-sync is on, and the renderer ends up waiting for large spaces of time. This could throw the game state off, and player input will be even more erratic. (And yes, I do want to be able to use v-sync.) IDEA 2 (triggered by this thread) I use multiple threads. The main thread controls the game state, and does a lot of sleeping, running only around 20 times a second. The renderer has its own thread, which runs as fast as possible, over and over. V-sync works just fine, since it will only stall that one thread, the main thread continues on as normal (and in fact benefits from the v-sync stalls by making better use of the CPU). Input as well has is own thread, and it too sleeps most of the time, waking up multiple times a second to poll for player input. PROBLEM The main problem here is the potential fight for CPU time. With the rendering thread running full speed, the other two threads will have to fight to get their updates done without causing game state or input stutters. One solution I read a lot involves messing with thread priorities, making the renderer a lower priority than the other two, so that they get a chance to run when they wake up. But this feels more like playing with fire to me, changing thread priorities and hoping it all works out. Unlike the single-thread method, where everything was linear and we knew for sure it worked as expected, I don't have as much faith in the thread priorities, and the various platforms the game may be ported to. And still, we have the issue of how often we need to poll for input, to balance between using too much CPU, and preventing input stutters from the delays. I believe DX has the option to use an event system for input, where the input thread is able to sleep until the player provides input, then it automatically wakes up to handle it. But I don't know if this is available for all forms of input (keyboard/mouse/joystick), and more importantly, I don't know that this is available on other platforms (heck, I don't know anything about game input under Linux right now). So, I feel stuck, there are pros and cons to both ideas, speed or latency issues either way. Anyone have some input on this, your own experiences or alternatives? Anything would be appreciated, I'm ready to move on from here. :)

Share this post


Link to post
Share on other sites
The rule is quite simple in the end: Thread overhead is not worth it, only thread what you must. Basically what you have right now sounds like a sound idea, if you want a thread to take up less of the timeslice you can have it check how long it's busy with GetTickCount and call Sleep(0) when it's exceeded it's slice according to you.

You could also have threads call longer Sleeps.

Share this post


Link to post
Share on other sites
Honestly, from my experiences, you only really want to mess with a few threads:

1.) A thread for rendering. This should only do rendering. You might want to just make it your main thread for simplicity's sake.

2.) A thread that handles AI, input, physics, and all other CPU-dependent stuff. Don't do a seperate thread for input; it's unnecessary and will probably cause you to get input lag.

3.) A thread for music and sound. Duh.

4.) A thread for networking. You MIGHT be able to put this one into the main thread, or the CPU-dependent thread, but it depends on your overall design.

5.) A thread for streaming in data. Duh.

Share this post


Link to post
Share on other sites
Buth when it comes to multithreading, is there an alternative to modifying thread priorities? Or maybe theres something I don't know about how threads cooperate? Making them sleep as much as possible is the best thing I can think of, but it still seems that they'll be competing a lot.

Etnu, the threads you have listed there sound good, though I know from your other posts that you're able to keep input in the main thread because you run it 100 times a second. This seems a little extreme to me, surely that creates some heavy CPU competition with the renderer thread? And given that, in a multiplayer game, the host is only broadcasting updates 10-20 times a second to the clients, it seemed redundant for all of the main loop to run faster than that. What are your thoughts there?

Share this post


Link to post
Share on other sites
1.) A good renderer should do as little as possible on the CPU. Your video card is powerful. Use it. Stop wasting time trying to make sure every little polygon that isn't visible isn't drawn. That's pointless. Use the graphics card's features. Occlusion queries. Lay down Z. The odds are that you're just wasting clocks with your culling algorithms if you're only pushing 5-10 million polys / sec.

2.) Priorities don't need to be modified much. Sleep(0) is usually good enough. Multi-tasking OSes like windows work remarkably well with seperate threads. Just check your processes tab...

3.)
Quote:

And given that, in a multiplayer game, the host is only broadcasting updates 10-20 times a second to the clients, it seemed redundant for all of the main loop to run faster than that.


Simple:


const float InputResolution = 0.01f;

float InputUpdateTimer = 0.0f;
while(true)
{
UpdateTimer += DeltaTime();
CheckForNetworkUpdates();
if(UpdateTimer >= InputResolution)
{
UpdateTimer = 0.0f;
QueryInput();
}
UpdatePhysicsStuff();
}



Share this post


Link to post
Share on other sites
Keep in mind here that the input engine is idle 90% of the time. Processing an action when you press the "up" key is not likely to eat many CPU resources.

Share this post


Link to post
Share on other sites
threads do not compete. They run during a given time slice (the quantum) and then return the control to the kernel which wake up another thread (and so on... only sleeping threads and threads which are in a "wait" state are not concerned).

If one of your thread do not have anything to do, then Sleep(0). It's easy and simple - it will only return the control to the OS which can then wake another thread.

Playing with thread proirity must be done only if you have a good understanding of what is done behind the scene. It will modify the way the OS allocates time quantums - and therefore may change the way your program is executed. This means that if your threads are communicating then you'll have to take care to the synchronisation of the threads.

Rising the priority of a thread will of course give it more time to execute - as a consequence, other threads will have less time. This is done by using the SetThreadPriority() function in Windows (see the msdn for further informations about this function and its parameters).

HTH

Share this post


Link to post
Share on other sites
It depends a lot on the OS, but the generally:

1. In a pre-emptive system (like Windows), threads of the same priority take turns. They switch after a small period of time or when the current thread relinquishes control.
2. In a cooperative system (like on a certain console), threads of the same priority take turns, however they switch only when the current thread relinquishes control.
3. Threads of a lower priority only run when no higher priority thread is ready to run.

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
... Rising the priority of a thread will of course give it more time to execute ...


That is not accurate.

Example: two threads have the same priority. Since they take turns, each gets about 50% of the time. If you raise the priority of one, it will get 100% and the other will get 0%.

Another example: two threads have different priorities. The higher priority thread relinquishes time occasionally, so the lower priority thread get about 30% of the time. If you raise the priority of the lower thread, but it is still lower than the higher thread, nothing will change.

Of course, this is simplified and depends on the OS.

Share this post


Link to post
Share on other sites

This topic is 4863 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      628710
    • Total Posts
      2984325
  • Similar Content

    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
    • By Dafu
      Hello all,
      I've been hard at work on a new retro pixel-perfect framework called FES Retro Game Framework. It is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      My own game I started working on using FES, a roguelike, very early: https://simmer.io/@Dafu/merl
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
       
       
    • By Apollo Cabrera
      Yasss!!! My first Unity3d game is on the App Store and Google Play.
      Download please! About 30 minutes to get through 5 missions.
      Let me know what you guys think.
      Thanks a bunch
       
    • By Mert Oguz
      well, i have started developing games last year, alone , I made a singleplayer 3d openworld rpg on unity you can look at it on googleplaystore ( kooru stone rpg ) whatever, this year, i wanted to make mmo, which gone really fine until I first try real hosting, I was working on "wamp" until then. The reason i am desperate now is that the way my game works.
      On my pc, using wamp mysql , with localhost as host for my game, i was testing my mmorpg with using andorid emulators, ofcourse no lag no issues no restrictions, beautiful dream... But then, I wanted to get real host from web, so, I rent a basic, cheaphest ever web host ( 10$ year ), and transferred my php files along with sql database. 
      So, I launched the game, still no issues, tried to handle 2-3 players by using my pc, phone, friend's phone...  
      After a while, ( after really short time (3-4mins)) host started not to respond, beacause those web hosting were not fit to handle mmos, i predicted that.
      now what i am explaining is that my game works like this and asking what way should i use to handle it :
      - Creates web request ( like : webhost.com/game/getplayerdata.php?ID=2 )
      -Reads request ( request result be like = "ID2-GoodGuyXx-23-123-4-123-43 )
      -Builds player using result string
      -does similar requests REEAALY FREQUENTLY  ( total requests of 8 - 12 times per seconds )
      With my current ultimate cheap web hosting, i can handle 2 players with low lag ( lol ) but, i want to handle around 20-100 players,
      just need a clear path, i have been struggling with google cloud sql and other vps server dedicated server options, i dont wanna pay much and get ripped off.
  • Popular Now