fatcoder
Member
|
Is World::update() multi-threaded?
The comments for World::update() state that it calls update on ever active game object. I'm just wondering if this is multi-threaded? i.e. are multi objects being updated at once if the system has more than one CPU core for example?
If not, is this a possibility?
|
|
12-16-2013 08:28 AM |
|
AndrewBGS
Member
|
RE: Is World::update() multi-threaded?
Great question! I'd like to know this too, it would be a pity if all objects in the world would be updated one after the other. I'd like to know the answer to this question too.
|
|
12-16-2013 08:46 AM |
|
KraaxLeNain
Member
|
RE: Is World::update() multi-threaded?
In this case this would mean that using World::update() would be more efficient than any use of Map<,> for storing displayed objects, despite the fact that it's harder to retrieve manually objects from it ?
|
|
12-16-2013 10:18 AM |
|
Esenthel
Administrator
|
RE: Is World::update() multi-threaded?
Hi,
Game.World.update processes all objects on the main thread for simplicity.
If you wish to have some processing done in multi-thread mode, then please do that outside of Game.World.update, for example using 'Threads' class or MultiThreadedCall
|
|
12-19-2013 12:46 AM |
|
AndrewBGS
Member
|
RE: Is World::update() multi-threaded?
Can we get to see the code for Game.World.update?
How would I go about updating each container (Players, NPCs, Statics, Items) on a different thread? I think this would be a great performance improvement that I would really like to get. But I have no idea how to do it.
|
|
12-19-2013 12:01 PM |
|
candam
Member
|
RE: Is World::update() multi-threaded?
Updating game objects using multithreaded operations will be a huge improvement I wish somebody could guide me to an example or tutorial or something
|
|
12-19-2013 01:19 PM |
|
Rubeus
Member
|
RE: Is World::update() multi-threaded?
(12-19-2013 12:01 PM)AndrewBGS Wrote: Can we get to see the code for Game.World.update?
How would I go about updating each container (Players, NPCs, Statics, Items) on a different thread? I think this would be a great performance improvement that I would really like to get. But I have no idea how to do it.
Create the object like normal, but do all the calculations on another thread. Before drawing, check that the update thread is done. It's not necessarily a "great performance improvement", although in some cases it can be.
|
|
12-19-2013 02:44 PM |
|
fatcoder
Member
|
RE: Is World::update() multi-threaded?
(12-19-2013 12:46 AM)Esenthel Wrote: If you wish to have some processing done in multi-thread mode, then please do that outside of Game.World.update, for example using 'Threads' class or MultiThreadedCall
Already doing that. However, it would be nice if we could get access to the list of active objects that the world will update, and then update them manually ourselves (instead of the world updating them).
|
|
12-20-2013 01:26 AM |
|
Esenthel
Administrator
|
RE: Is World::update() multi-threaded?
You can do that by iterating through all active areas (Game.World.areaActive) and accessing their list of objects (Game.Area.objs)
For next release I'll add those methods:
Code:
Game.World:
Int areaActiveNum( )C; // get number of active areas
Area* areaActive ( Int i )C; // get i-th active area , if the index is out of range then NULL is returned
|
|
12-20-2013 01:42 AM |
|
AndrewBGS
Member
|
RE: Is World::update() multi-threaded?
I'm sorry I'm still not sure how this would work;
I want to run update, drawPrepare and drawShadow - I believe these are the most time-consuming - for every object class (or every area, we'll see) in separate threads.
So instead of using the Game.WorldUpdate(), I would do the iteration through areas and containers and run object[i].update on all of them? This is enough to replace Game.WorldUpdate?
Also, how would I go about the drawShadow and drawPrepare? Having those on separate threads should make the game move a lot quicker (unless those are already multi-threaded).
|
|
12-20-2013 09:21 AM |
|
fatcoder
Member
|
RE: Is World::update() multi-threaded?
(12-20-2013 01:42 AM)Esenthel Wrote: You can do that by iterating through all active areas (Game.World.areaActive) and accessing their list of objects (Game.Area.objs)
OK, that will work, especially with the new methods. However, to it would be good if we could optionally tell World::update() not to call update on the objects. That way we can call update on each active object ourselves manually as needed.
For example, you could add another Bool to WorldManager called something like skip_object_update. Then the WorldManager would just skip over calling update on every object if this is set to true. The World::update() call would still do everything else such as calculating the active areas and active objects for example.
That would really make these extra methods you are adding very useful if this is possible.
|
|
12-20-2013 11:19 AM |
|
Esenthel
Administrator
|
RE: Is World::update() multi-threaded?
@AndrewBGS: You can't do multi thread drawing as it would be slower due to thread synchronization.
This is not the slow part, but the slow part it's the GPU executing those commands.
|
|
12-20-2013 09:20 PM |
|
fatcoder
Member
|
RE: Is World::update() multi-threaded?
You're probably talking to Andrew, but just to clarify, I'm not talking about multi-threaded rendering. I'm talking about updating objects. I'm using a different approach to "objects" in a project I'm working on, which means they aren't updated in the traditional way. I want to stop EE from wasting time trying to update every object when it isn't needed as I'm handling it in a different way.
|
|
12-20-2013 10:32 PM |
|