OnWorldLimit is implemented differently from other callbacks
by Jason Swearingen · in Torque Game Builder · 08/23/2005 (8:52 pm) · 2 replies
OnWorldLimit is the only callback that checks if the event is hooked by a torquescript function before executing.
If this does not add any appreciable amount of performance, I request that this check be removed.
The reason why, is that I hook (in C++) all callback events via the Con::executeF function, and the only callback that I can not do this with is onWorldLimit. For this function, I need to hook the fxSceneObject2D::processWorldLimitCollision directly. (not as elegant)
The line i would like ommited is: (on aprox line 3846 of fxSceneObject2D.cc)
Again, if this seriously impacts performance, then nevermind, but in my checks it doesnt seem to effect performance to any noticable degree.
If this does not add any appreciable amount of performance, I request that this check be removed.
The reason why, is that I hook (in C++) all callback events via the Con::executeF function, and the only callback that I can not do this with is onWorldLimit. For this function, I need to hook the fxSceneObject2D::processWorldLimitCollision directly. (not as elegant)
The line i would like ommited is: (on aprox line 3846 of fxSceneObject2D.cc)
if ( mWorldLimitCallback )
Again, if this seriously impacts performance, then nevermind, but in my checks it doesnt seem to effect performance to any noticable degree.
#2
fxSceneObject2D::processWorldLimitCollision is the only callback that actively checks if a callback exists before executing Con::executef
it's not terribly hard for me to circumvent this check, i just thought it's a bit unusual that onWorldLimit is the only callback that actively checks first.
So if it's a pain or impacts something else, no worries Melv :)
=============
a bit of a background on why i am doing it this way (and why setting mWorldLimitCallback=true doesnt really work for me):
I am using C# to interop with the C++ code, and have user-defined delegate functions that get executed for the callbacks, instead of torquescript callbacks.
Because of how I do this, it isnt trivial to have the C++ function fxSceneObject2D::processWorldLimitCollision determine if the delegate exists, and it isnt trivial to set mWorldLimitCallback=true when the c# delegate is set.
I can do the work, but i am trying to modify the C++ code as little as possible, that is why i like the fact that for all callbacks (Besides onWorldLimit) I can hook the Con::executef() function, and not even touch any of the other callback-generating functions.
08/24/2005 (12:19 pm)
I guess what I'm saying is that none of the other callback functions actively look for if a callback exist before executing Con::executeffxSceneObject2D::processWorldLimitCollision is the only callback that actively checks if a callback exists before executing Con::executef
it's not terribly hard for me to circumvent this check, i just thought it's a bit unusual that onWorldLimit is the only callback that actively checks first.
So if it's a pain or impacts something else, no worries Melv :)
=============
a bit of a background on why i am doing it this way (and why setting mWorldLimitCallback=true doesnt really work for me):
I am using C# to interop with the C++ code, and have user-defined delegate functions that get executed for the callbacks, instead of torquescript callbacks.
Because of how I do this, it isnt trivial to have the C++ function fxSceneObject2D::processWorldLimitCollision determine if the delegate exists, and it isnt trivial to set mWorldLimitCallback=true when the c# delegate is set.
I can do the work, but i am trying to modify the C++ code as little as possible, that is why i like the fact that for all callbacks (Besides onWorldLimit) I can hook the Con::executef() function, and not even touch any of the other callback-generating functions.
Associate Melv May
All collisions also have the option if a callback is made.
Can't you just set the world-limit callback to yes when you set it?
- Melv.