Lag time by using the global variable when moving blocks.

spidey906

Hi,

I am making two blocks. One on bottom and the other on top. I also make a global x coordinate equal to the x coordinate of the bottom block. Then make the x coordinate of the upper block equal to the global x variable.

They move together according to the X coordinate, but there is still some lag time. How I can solve it. Many Thanks.

K.C.

tatiang

1. You can try unlocking the upper block and constraining its self.position.X to the lower blocks self.position.X. That will alleviate the need for "global" game attributes.
2. You can tell us how you are moving the bottom block (e.g. Move behavior, drag and drop via constrain to mouse position, etc.) and how quickly (e.g. speed=50, speed=600, etc.).
3. You can post a video showing an example of the lag.
4. You can post your rules for the two blocks.

Socks

I'd say the single biggest cause of lag is layer order, swap their layer order and see if that solves your problem.

The_Gamesalad_Guru

Scene linking as @tatiang describes is best. I have done tests on this and I always use scene links for attaching things.

tatiang

I'd say the single biggest cause of lag is layer order, swap their layer order and see if that solves your problem.

Do say more...

gyroscope

Hi @kentcheung2000@yahoo.com

Good advice from @tatiang, @Socks and @FryingBaconStudios

To add: whatever the cause of the lag, the possibility that it's caused by using a global attribute instead of a scene or self attribute is practically nil.

LiquidGameworks

@tatiang With constrains, I've found that if the "Constraining actor" is above the "constrained actor" in layer order, it will sometimes cause significant lag and jitters. Though, this occurred many versions ago, and haven't experienced it since.

tatiang

@tatiang With constrains, I've found that if the "Constraining actor" is above the "constrained actor" in layer order, it will sometimes cause significant lag and jitters. Though, this occurred many versions ago, and haven't experienced it since.

Weird. I'd never heard of that, but thanks for the info! I have a sports game on hold because I ran into so many jitters with constraints... maybe I should go look at it again.

spidey906

Thanks for your solution in constraint. I think this solve the problem.

The_Gamesalad_Guru

This seems worthy of some experiments. Off to my mad scientist lab.

The_Gamesalad_Guru

Okay here are the results. The first test is with tradition external attributes the second uses scene linking. As you'll see the scene linking provides noticable results.

gyroscope

@FryingBaconStudios Interesting tests, Dave. :-)

I'm certain you know the third way to ensure a "no lag drag"; – I'll mention it for anyone else's info:

put the following Rule in one actor (nothing in the other):

Rule: When Touch is pressed
Constrain Attribute self.Position.X to game.Touches.Touch 1.X
Constrain Attribute self.Position.Y to game.Touches.Touch 1.Y
Constrain Attribute scene.Background.Actor 2.Position.X to self.Position.X
Constrain Attribute scene.Background.Actor 2.Position.Y to self.Position.Y

tatiang

Thanks, @FryingBaconStudios! And layer order...?

@gyroscope... isn't that cheating? Cool idea, I hadn't thought of that.

Socks

@tatiang

I'd say the single biggest cause of lag is layer order, swap their layer order and see if that solves your problem.

Do say more...

Try it yourself, change the order of the 'handle' and the 'head':

http://www.mediafire.com/?9181p3ea2tjf9bx

The_Gamesalad_Guru

Tried it both ways and scene linking still blew it away. I usually perfer to only unlock the actor I'm attaching as I can keep the prototype locked of the main actor

The_Gamesalad_Guru

Nothing like a live test to prove things out.

gyroscope

@FryingBaconStudios Very true, Dave! :-)

...to ensure a "no lag drag"; – I'll mention it for anyone else's info:

put the following Rule in one actor (nothing in the other):

Rule: When Touch is pressed
Constrain Attribute self.Position.X to game.Touches.Touch 1.X
Constrain Attribute self.Position.Y to game.Touches.Touch 1.Y
Constrain Attribute scene.Background.Actor 2.Position.X to self.Position.X
Constrain Attribute scene.Background.Actor 2.Position.Y to self.Position.Y

@gyroscope... isn't that cheating? Cool idea, I hadn't thought of that.

Hi @tatiang Not sure if you meant this "tongue-in-cheek" or not.... ;-) If not, I'm interested to know in what way you think it might be cheating?

-------
Edit: ah, I think I'm understanding: there IS a lag time using intermediary attributes in this case, but for the record, @kentcheung2000@yahoo.com , there will still be a lag whether it's an extra set of scene, self or global attributes used; the reason being that you're adding an extra "layer" of processing which isn't needed.

So I guess, @tatiang, you mean my solution I gave, although it works, doesn't involve any intermediary attributes... so it's sort of cheating (?!)... don't know still... anyhow, time I had a cup of tea.... :-) ~O)

The_Gamesalad_Guru

My rules are the same I just put the scene lock in the actor that does nothing more than attach it's self to the main actor. That way I don't need to unlock my main actor and keep prototype status intact as the main actor will carry all the other associated rules.

tatiang

@gyroscope yes, tongue-in-cheek. Forgot the :P

I called it "cheating" because I've never though to constrain another actor's attributes to an unlocked actor that way. As in, "you can do that?!"

Socks

Tried it both ways and scene linking still blew it away.

Scene linking has a noticeable lag when compared to simply changing the layer order in my example. Scene linking might be better than referencing a global attribute, but ordering the layers seems to have to biggest impact on reducing lag.

The_Gamesalad_Guru

I tried changing the layer order @socks and for me it was the same with external attributes vs scene link. Also when exporting to device the lag goes away that does show on GS preview.