Void ProcessList::advanceObjects()
by Dumbledore · in Torque Game Engine Advanced · 12/21/2008 (2:45 pm) · 4 replies
It looks like this method just adds each ProcessObject to the end of the linked list until it has iterated through the entire ProcessList.
The ProcessList::advanceTime(SimTime timeDelta) method calls advanceObjects.
What is the point of ProcessList::advanceTime(SimTime timeDelta)?
Is there an advanceTime() for each GameBase derived object?
Finally, where are animation interpolations calculated (to step between keyframes) and does this have anything to do with advanceTime() or is it in a separate thread like TSThread?
Oh, I guess one other thing... where is the code that parses the .DTS files to generate the vertex list?
Thanks for any help.
The ProcessList::advanceTime(SimTime timeDelta) method calls advanceObjects.
What is the point of ProcessList::advanceTime(SimTime timeDelta)?
Is there an advanceTime() for each GameBase derived object?
Finally, where are animation interpolations calculated (to step between keyframes) and does this have anything to do with advanceTime() or is it in a separate thread like TSThread?
Oh, I guess one other thing... where is the code that parses the .DTS files to generate the vertex list?
Thanks for any help.
#2
ProcessList::advanceTime ultimately calles the time callbacks on each GameBase-derived object. Look at the GameBase header; there are only a few of these functions and they are documented.
Eventually execution get into the 3space library, contained in the ts directory and with its classes prefixed with TS, and it is this code which deals with animation, rendering, and collision for DTS models.
Like Stefan says, nothing in TS has anything to do with multiple threads.
If you are curious how this stuff works in detail, the best thing to do besides reading any docs/forum threads you can find, is to hit F12 to break into the debugger during a frame, then single-step through to see how everything is being called.
12/21/2008 (4:44 pm)
ProcessList keeps track of objects that need to get called as time goes by, and does this. It is a little complicated because it takes into account ticks vs. interpolation (ticks are guaranteed to happen 32 times/sec, while interpolation only happens between ticks if the framerate is high enough).ProcessList::advanceTime ultimately calles the time callbacks on each GameBase-derived object. Look at the GameBase header; there are only a few of these functions and they are documented.
Eventually execution get into the 3space library, contained in the ts directory and with its classes prefixed with TS, and it is this code which deals with animation, rendering, and collision for DTS models.
Like Stefan says, nothing in TS has anything to do with multiple threads.
If you are curious how this stuff works in detail, the best thing to do besides reading any docs/forum threads you can find, is to hit F12 to break into the debugger during a frame, then single-step through to see how everything is being called.
#3
The one thing I'm still not sure on is how ProcessList::advanceTime ultimately calls any time callbacks for GameBase objects. I'm either blind, or that statement isn't true, because I cannot see where it is calling any methods besides "advanceTime" and advanceTime just seems to be reshuffling the the processList of processObjects.
Thanks again, and I will now continue on my path of discovery.
12/21/2008 (6:03 pm)
Thanks for info Ben. Good idea, I will try stepping through the code. The one thing I'm still not sure on is how ProcessList::advanceTime ultimately calls any time callbacks for GameBase objects. I'm either blind, or that statement isn't true, because I cannot see where it is calling any methods besides "advanceTime" and advanceTime just seems to be reshuffling the the processList of processObjects.
Thanks again, and I will now continue on my path of discovery.
#4
The confusion as to how ProcessList is understandable (only subclasses of ProcessList do anything) but at the same time it's a perfect example of how using your debugger would make things much clearer. Try this for me - go to gameBase.h and look at GameBase. You'll find that there are several methods related to ticking. Take one of those, like processTick, and put a breakpoint in the Player's implementation of it.
Now run it, look at the call stack in the debugger once it breaks, and see if how ProcessList works is a lot more obvious. :)
As a side note: shame on whoever did the last major update to ProcessList and didn't take the time to document it.
12/21/2008 (7:13 pm)
The list is sorted based on some dependency knowledge. Ie if object A depends on the state of object B (say A is standing on top of B) then it makes sure that A processes after B. That's what the linked list shuffling is about.The confusion as to how ProcessList is understandable (only subclasses of ProcessList do anything) but at the same time it's a perfect example of how using your debugger would make things much clearer. Try this for me - go to gameBase.h and look at GameBase. You'll find that there are several methods related to ticking. Take one of those, like processTick, and put a breakpoint in the Player's implementation of it.
Now run it, look at the call stack in the debugger once it breaks, and see if how ProcessList works is a lot more obvious. :)
As a side note: shame on whoever did the last major update to ProcessList and didn't take the time to document it.
Torque Owner Stefan Lundmark