It looks like you're new here. If you want to get involved, click one of these buttons!
void CastleSiege::MoveToDest(ScrollObject &obj, orxVECTOR worldDest)
{
orxVECTOR currentPos, direction, directionN, speed;
obj.GetPosition(currentPos);
orxVector_Sub(&direction, &worldDest, ¤tPos);
orxVector_Normalize(&directionN, &direction);
orxVector_Mulf(&speed, &directionN, 60.);
speed.fZ = 0.;
obj.SetSpeed(speed);
orxFLOAT len = orxVector_GetSize(&direction);
orxFLOAT lenSpeed = orxVector_GetSize(&speed);
orxFLOAT estTime = len / lenSpeed;
orxCLOCK *coreClock = orxClock_FindFirst(orx2F(-1.0f), orxCLOCK_TYPE_CORE);
orxClock_AddTimer(coreClock, StopMovable, estTime, 1, &obj); // .GetOrxObject()
}
void StopMovable(const orxCLOCK_INFO *clockInfo, void *movable)
{
ScrollObject *obj = static_cast<ScrollObject*>(movable); // failed to make it a reference
obj->SetSpeed(orxVECTOR_0);
// orxObject_SetSpeed((orxOBJECT*)movable, &orxVECTOR_0);
}
Comments
Yes, it totally fine and there's actually a shortcut for adding timers to the core clock (as shown in the code snippet below).
One only needs custom clocks either for optimization (and having a piece of code run at say 10Hz instead of 60Hz) or for doing local time stretching (more below).
Yes, this is for doing per object time stretching. If you link a custom clock to an object, you can then modify that clock's DT and either slow down or speed up the update of that object. It'll also affect all the object components (like changing the pitch of sound playing on it, etc). Many objects can be linked to the same clock.
Here's the version I propose for your method, assuming the timer's callback is declared as static in the CastleSiege class:
As shown above, you can remove the previous timer before adding a new one, if there were no timer, it won't do anything.
I typed that code directly in the forum, so it's not tested but it should be mostly fine, hopefully.
I was worried that ''orxClock_RemoveGlobalTimer'' would remove incorrect function, but it does not. I had 3 objects moving at the same time, I changed their directions while others are moving and each time objects behaved as expected.
It appears that registration takes into consideration context object.
It also does filtration based on the delay.
-1 for the delay or orxNULL for the context will deactivate the respective filters.