Removing object 'lag'

This is a bug in Sticky Object that I came around in MMF1.5 by using OEFLAG_BACKGROUND so it was processed before any other active object but it doesn't seem to work in MMF2.

Basically I want to move objects when their parent moves but everything seems to be one frame behind. Aren't the hoX/hoY coordinates properly updated when an object is moved? How do I find the most current position of an object then?

I also thought it might be MMF2 not updating the position of the objects before the next frame so I tried using callRunTimeFunction with RFUNCTION_SETPOSITION. That caused the objects not to move at all for some reason.

What should I do? :)

Do you set the roc.rcChanged flag to 1 after changing the position?

Yes I do. The object updates its position fine, it's just that it is one frame behind.

Hmm... maybe try sending your object to Francois?

This is how I move objects if that helps:

Code:

---

LPRO obj1=(LPRO)CNC_GetParameter(rdPtr);  //or any other thing
if(obj1==NULL) //stop crashes
        return -1;
obj1->roHo.hoX=x;//move the object
obj1->roHo.hoY=y;
obj1->roc.rcChanged=1;//updates the object
return 0;

---

All I remember is that there was an extension, I think, that dealt with that problem, prior to MMF2.

I think there was something about the movement being processed before and not after each cycle that caused the problem, according to the author.

Yeah I think Alien found some way to immedeatly update objects. (by using code snippet from you Yves I think)

I move all objects if needed in the HandleRunObject function:
(Code snippet from relative attach)

Code:

---

Child->roHo.hoX = Child->roHo.hoX + (Parent->roHo.hoX - rdPtr->Attached->at(i).ParentX);
Child->roHo.hoY = Child->roHo.hoY + (Parent->roHo.hoY - rdPtr->Attached->at(i).ParentY);
//Some other code in-between to update offsets
Child->roc.rcChanged = true;

---

As far as I remember when programming the Lens object, the hoX and hoY positions are always one frame behind (made the Lens object lag like this object does now when displaying the background and moving at the same time)
It was because I used hoX and hoY to get the background from it's position, but I quickly found out to use to the rect-top/left values instead as they were up to date. I can't really do that in this extension... Or can i? :-/

Quote:

---

Or can i?

---

Ask Francois directly, probably he didn't see this post. I would have to look at his source code to see where and when you can use hoRect and I'm not sure if I would be able to give you a 100% correct answer.

Is any of the following flags set in the OEFLAG of you object? OEFLAG_ANIMATIONS, OEFLAG_MOVEMENTS, OEFLAG_SPRITES
If not, then the object is not updated at the end of the loop. Usually a RCom structure (the one which contains the rcChanged flag) is only present when one of these flags is set. So if it is not, I do not see how I can correct that...

What do you mean?

None of those flags are set because my object isn't a graphical object. I tried using them and inserting the structures they use but it didn't fix the delay.

So then what? Did something in MMF2 change since it isn't possible anymore? It seemed to work perfectly in MMF1.5 when I used the OEFLAG_BACKGROUND flag by itself to force MMF to handle my object before any object on the 'active' layer.

No, it did not work in MMF1.5. In MMF2.0 I added a special loop after the call to the events to update the position of the objects with the flag rcChanged at 1. This is why it works in MMF2.
If your object does not contain any of the flags, the rCom structure is not "officially" created (you have it in your RUNDATA structure, but it is not used by the runtime), and the changed flag is not tested after the events.
I could add the BACKGROUND flag to the list of flags necessary for the rcom structure, but this would imply changes in the other objects with the background flag.

My object doesn't need to have it's rcChanged flag set in order to work. It should just sit back and monitor if one object has moved and then move other objects attached to the given object. I don't see why my object should have any of those flags then.

Back in MMF1.5 I just used the OEFLAG_BACKGROUND to make sure my object's HandleRunObject function was called before all other objects (since it would be behind all other objects it would be one of the first objects in the object list to be handled by MMF)

It is in the HandleRunObject function of my extension I change the position and set the rcChanged flag of other objects which I have stored in an internal list.