Process List, Gamebase and iTickable.
by Kent Butler · in Torque 3D Professional · 03/06/2016 (10:23 pm) · 2 replies
Howdy. I'm finally looking to possibly port a significant bit of engine work from TGE into T3D and am hoping to get some feedback on an issue that appears to hold-over from TGE regarding how the process list is handled.
The issue in TGE is that process list manipulation is defined at the Gamebase level. Mostly this isn't a problem, but there are some significant edge cases where this effectively puts the process list outside the scope of classes that need to be able to manipulate it. Significantly, I've run into issues working with coordinate-space based attachment schemes (at the sceneobject level) and again in the context of a tickable mapping gui.
So far I have only superficially looked over the T3D codebase and noticed that the process list functionality has been reorganized and expanded. It also still appears to be a component of gamebase. In the iTickable code (both in TGE and T3D) there are TODO comments that indicate a plan to move the process list functionality from gamebase into the iTickable interface. From a TGE perspective this seems like it would be a pretty solid improvement. But at this point it doesn't appear to have been implemented in the more recent versions of Torque either.
I'm wondering if things evolved differently to the point where such a change no longer makes sense - or if it's just an issue that doesn't come up for enough people to lead someone to invest in that part of the engine.
Does anyone have thoughts on the topic from a T3D perspective?
The issue in TGE is that process list manipulation is defined at the Gamebase level. Mostly this isn't a problem, but there are some significant edge cases where this effectively puts the process list outside the scope of classes that need to be able to manipulate it. Significantly, I've run into issues working with coordinate-space based attachment schemes (at the sceneobject level) and again in the context of a tickable mapping gui.
So far I have only superficially looked over the T3D codebase and noticed that the process list functionality has been reorganized and expanded. It also still appears to be a component of gamebase. In the iTickable code (both in TGE and T3D) there are TODO comments that indicate a plan to move the process list functionality from gamebase into the iTickable interface. From a TGE perspective this seems like it would be a pretty solid improvement. But at this point it doesn't appear to have been implemented in the more recent versions of Torque either.
I'm wondering if things evolved differently to the point where such a change no longer makes sense - or if it's just an issue that doesn't come up for enough people to lead someone to invest in that part of the engine.
Does anyone have thoughts on the topic from a T3D perspective?
#2
For example, with a platform mover that allows players to arbitrarily run around on the moving object while it's moving. Rendering order for multiple players (attached to the same moving object) is completely arbitrary based on where they've ended up in the process list. The player at the end gets a good sim while everyone else has at least one other player object rendering a frame out of sync. GG handles this issue for objects mounted the traditional way by sorting the process list at render to manually process child objects and make sure every connection has a syncronized sim. It's not possible to pull the mover functionality off without going into sceneobject ... and it's not possible to access the gamebase-defined sorting routines from the sceneobject scope.
The way you are describing the TGB/T2D situation, it sounds like you have been *restoring* a process list functionality that was no longer present at all. Is that a correct understanding?
Did the TGB/T2D approach you are unwinding fully implement all of the process list sorting functionality from gamebase into iTickable? Or did they just try moving to using the iTickable interface without improving it to support the extended functionality currently in Gamebase?
I can't grasp why moving the full functionality from being directly defined in the gamebase class to being implemented in the class through an interface would have such an aggressive negative carry-on impact. I've done a solid amount of preliminary planning to implement the change in TGE and I'm not seeing how my planned approach would break the functionality you are describing.
I'm confident I can engineer a completely functional solution in TGE. It just feels sort of wasteful to be throwing all of my time into the older engine where nobody else can benefit from the work. OTOH, I really know TGE's codebase quite well by now. So maybe it'll be better to just roll with the old backbone after all. It's not like I'm doing a AAA title or anything.
03/07/2016 (8:38 am)
Thanks for the input. Actually, the problem ends up manifesting such that objects in the process list that are unable to sort themselves can run into a number of unfortunate rendering issues specifically in a networked environment.For example, with a platform mover that allows players to arbitrarily run around on the moving object while it's moving. Rendering order for multiple players (attached to the same moving object) is completely arbitrary based on where they've ended up in the process list. The player at the end gets a good sim while everyone else has at least one other player object rendering a frame out of sync. GG handles this issue for objects mounted the traditional way by sorting the process list at render to manually process child objects and make sure every connection has a syncronized sim. It's not possible to pull the mover functionality off without going into sceneobject ... and it's not possible to access the gamebase-defined sorting routines from the sceneobject scope.
The way you are describing the TGB/T2D situation, it sounds like you have been *restoring* a process list functionality that was no longer present at all. Is that a correct understanding?
Did the TGB/T2D approach you are unwinding fully implement all of the process list sorting functionality from gamebase into iTickable? Or did they just try moving to using the iTickable interface without improving it to support the extended functionality currently in Gamebase?
I can't grasp why moving the full functionality from being directly defined in the gamebase class to being implemented in the class through an interface would have such an aggressive negative carry-on impact. I've done a solid amount of preliminary planning to implement the change in TGE and I'm not seeing how my planned approach would break the functionality you are describing.
I'm confident I can engineer a completely functional solution in TGE. It just feels sort of wasteful to be throwing all of my time into the older engine where nobody else can benefit from the work. OTOH, I really know TGE's codebase quite well by now. So maybe it'll be better to just roll with the old backbone after all. It's not like I'm doing a AAA title or anything.
Torque Owner Nathan Martin
TRON 2001 Network
In old TGB and T2D they did move to iTickable for object tick timing, but in turn destroyed real-time networking in the process.
I've spent the past month undoing that damage to restore real-time networking for an old iT2D/TGB hybrid engine and it involved bringing ProcessList (NetworkProcessList in T2D) back to life along with the aforementioned MoveManager and control object integration.
If code you're wanting to port over from TGE to T3D doesn't involve networking or at least doesn't need to be client controlled nor client-side predicted then using iTickable for time processing is an available option, else you're stuck with inheriting GameBase and the inherent responsibilities.