In my design, every mover will carry at least one thread.
And also, every game object carries at least one thread too.
If the IK is *NOT* a mover, unlike other stuff like the pathfinder and physics,
which each of them has a least one thread, then IK will be handled by the game object thread.
when the game object is updating the IK, it will deal with the IK there.
Other stuff like pathfinding, when looping the game object, it will issue requests to pathfinder,
and the pathfinder thread will work on it and tell the game object it has finished the job and you can interpolate on the waypoints?
Thanks
Jack
Can the IK subsystem be described as a "Mover"?
Author
I'm not familiar with this "mover" vs "not mover" idea. Does anything stop working right if you arbitrarily put the IK in the "mover" category or the "not mover" category? If so, then that's the answer. Otherwise, pick either one.
What I'm worried about: Each thread has a separate thread stack in RAM. Start too many threads and you'll waste a LOT of RAM.
If you plan on using threads heavily, consider using a fixed number of threads (a thread pool) which poll for tasks (independent batches of data that need to be processed). Then you can make the tasks be anything you want.
What I'm worried about: Each thread has a separate thread stack in RAM. Start too many threads and you'll waste a LOT of RAM.
If you plan on using threads heavily, consider using a fixed number of threads (a thread pool) which poll for tasks (independent batches of data that need to be processed). Then you can make the tasks be anything you want.
Author
Yes, you certainly fix my problem.
I have a thread embedded in each object.
So it becomes a large overload...
Thanks
Jack
Author
If I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider
should I open 14-15 threads including one main thread?
But I am still having doubts abou the one thread per object approach.
9 threads in game objects is a resource hog and also the main thread
has nothing to do at all!!
If not otherwise, should I throw the game objects into a loop, or should
I submit requests on regular basis?
Wherever you have a system which may use a lot of threads, consider creating a thread pool.
A thread pool basically manages allocation of and recycling of threads so that the load is split evenly between a set number of threads e.g. 8 or 16 (just an example) based upon what is optimal for the hardware rather than just letting the thread allocation run out of control.
This might solve a few problems if you really must thread pathfinders etc.
Personally I'd have one pathfinding thread, and queue requests in that thread, passing back responses to the requestor on completion. Only if the queue is getting unreasonably long during play might I consider multiple path finding queue threads but this would be set at compile time rather than runtime.
Just my own 3 cents (2 cents adjusted for inflation)...
A thread pool basically manages allocation of and recycling of threads so that the load is split evenly between a set number of threads e.g. 8 or 16 (just an example) based upon what is optimal for the hardware rather than just letting the thread allocation run out of control.
This might solve a few problems if you really must thread pathfinders etc.
Personally I'd have one pathfinding thread, and queue requests in that thread, passing back responses to the requestor on completion. Only if the queue is getting unreasonably long during play might I consider multiple path finding queue threads but this would be set at compile time rather than runtime.
Just my own 3 cents (2 cents adjusted for inflation)...
One thread per object is a terrible idea. One thread per system (or mover, or whatever you want to call them) is also a terrible idea.
The number of threads should match the capabilities of the hardware.
As Nypyren says, you should have a fixed number of threads in a thread pool, and then your objects and systems should generate tasks for that thread pool to execute.
This way you can keep the CPU as busy as possible, without wasting resources.
Having too many threads just means a bunch of them are sleeping and do nothing but waste resources and will make your program execute slower.
There is not much point in having many more ready-to-run threads than you have CPU-cores.
Mostly a single CPU-core can work on one thread. This is not entirely true, eg hyperthreading does 2 threads, but at a reduced speed.
If you start 15 threads on a dual core machine, about 12 of the 15 threads are just blocked on not having a CPU-core to run on.
Edit: Ninja'd by Olaf Hedman
Edit2: Add "-core" to the CPU, to clarify.
I had 9 objects in the scene, 2 pathfinders, 1 physics, 1 collision avoider should I open 14-15 threads including one main thread?No no no. No thread pools. No thread anything. You stop using threads right now. No idea where you got this "one thread per object" idea from.
Do a single game loop in the main thread for now.
No idea where you got this "one thread per object" idea from.
Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.
However, I see where you're going with your recommendation to avoid threads. Threads are a nightmare for even an experienced developer and should be used with extreme caution.
If there really is no other way, this is when you use threads, for example pathfinding several thousand actors across a gigantic navmesh in realtime whilst doing other AI and physics etc. Most of the big game engines have separate threads for things like physics and pathfinding, but they are much more complex systems, perhaps the adage applies: Keep It Simple.
Sounds like java code smell to me, the usual java way is to assume resources are unlimited and let the jvm deal with it.I'm going to blame every little single thing any C++ programmer does on the language. Every single one of them.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
