Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Wow I could run a simulation of a game on multiple threads with this but...

Discussion in 'Experimental Scripting Previews' started by Arowx, Feb 15, 2017.

Thread Status:
Not open for further replies.
  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    OK I write a simulation/game that will run on multiple threads but what does Unity provide that will ensure I can maintain a 60 fps on my game?

    Let's say I use Parallel foreach on my loops to allow lots more NPCs to be active in a simulated game world but how can I limit my program to ensure it maintains a 60fps for the main character/player?

    This is not simple as the Unity engine provides physics, sfx, particles, terrain and UI rendering something I need to maintain for the player even as the world around them evolves and changes.
     
  2. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,965
    Nothing. There is no way to ensure that. There are simply too many variables.
     
  3. Zuntatos

    Zuntatos

    Joined:
    Nov 18, 2012
    Posts:
    612
    You can run with all the threads you want already, it is just a bit more syntax (and you need to gather the results to the main thread to apply them to unity objects, but that remains)
     
  4. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    exactly, which is also the way its usually done. you have one main manager thread and if you have things that you can split out and distribute onto multiple threads, then you manage it yourself.

    I don't really see why (or what even) unity would provide anything in regards to this.
    No application of multi-threading to a problem can be applied to all problems. Its just a difficult (well... relatively :p) process.

    Maybe you can elaborate a bit more what exactly you mean?

    You would limit the amount of work by splitting it into chunks in some way and only process more (in a single frame) when you are sure you still have time left.

    Or in other words: Don't process all of your NPCs / Entities / whatever_it_is once every frame, but maybe split them into two / four / ... groups and only process one group every frame.
     
  5. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Maybe some kind of time gate mechanism that would flag up when threads should stop working on this frames information so it can be processed by the main thread.

    And it would need to work with Unity as multiple threads working when Unities multi-threaded task system runs would just get in the way of each other.

    So you would have a game processing window within a frame that would provide enough of a margin to allow you to run your game without going over budget and dropping/delaying a frame.

    Also it would have to work with the physics engine frames.
     
  6. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    That's all stuff you will have to manage yourself.
    And it's really not that hard.
    Also it's not something Unity can provide in any shape or form because the requirements are waaaay too different from user to user.

    Depending on what you want to do it can be done in like 3-4 lines tops.
    It's not something you'd need an API for :)

    As for time gating: You'd do time management when you only have one thread that needs to do other things.
    But you're talking about having multiple threads. So there's no time management, you queue work and eventually it gets done. You only need to manage your time slices when you *don't* have multiple threads (so there's enough time left to render a new frame for example)
     
  7. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Not the right place for this.
     
Thread Status:
Not open for further replies.