How do I smooth move forward?

Hello World,

So I need to make a smooth following camera, at the moment my game keeps hanging for like a split second once in a while. And I can't use the "scroll to" behavior on my character so I can put lerp on it. I don't remember exactly why I can't use "scroll to", but I do remember that way back when I started working on the game I tried "scroll to" and it didn't work with my other systems.

So right now my scrolling is done with the "move forward" action on every tick. Is there any way I can use lerp with that? Or maybe something else for "move forward" to make it smooth?

Here's how things are set up:

Event: Character is on layer

subevent: every tick; action: PlayerBox move forward 1.3 pixels

subevent: every tick; action:set Character position to PlayerBox(image point 0)

Event: every tick; action: scroll to(PlayerBox.X, 400)

PlayerBox is just an invisible sprite I attached the character and movement to.

One thing you can do is incorporate dt in the move forward action. The frame time can fluctuate from frame to frame and dt is the current frame time.

So instead of 1.3 use 1.3*60*dt.

every tick is framerate dependant, search for delta time dt and/or framerate independant movement..

also instead of setting the character every tick, why noy pin the character to the playerbox?

I tried using dt like you suggested R0J0hound and the game doesn't hang anymore, instead now it kinda "skips" back and forth(very fast, both movements in like a split second) where the hangs would be. Suggestions?

LittleStain I thought I already did that. As you can see from my events the character doesn't move, the invisible playerbox object has the movement on it, while the character just adjusts it's position to the playerbox object every tick. Is that what you are reffering to when you say "pin" or is it something else all togheter?

With pin I was referring to the pin-behaviour instead of setting position every tick..

Ok, I tried the pin behavior LittleStain, seems to work pretty much the same. Are there any advantages/disadvantages to using the pin behavior instead of what I was doing?

Bump.

Less code in the long run, and easier to implement. Also less chance of 1 sprite going walkabout without the other.

You can also look at containers. Add your playerbox to character.

I also like to have instance variables that store current x,y of moving sprites... has lots of use down the road from undo buttons to savepoints etc.

So many ways to achieve same thing. But the best way is completely dependent on what you want, what are you comfortable with etc etc.

I guess that makes sense DUTOIT ty. What about the problem with my game hanging, any more ideas guys?

I guess that makes sense DUTOIT ty. What about the problem with my game hanging, any more ideas guys?

Sorry, can't picture it. But are you *dt?

Which scroll to you using? The behaviour or via system. Because the behaviour is the one you want... its just about enabling it. Nothing magic. It just works.

All of those questions can be answered if you read my first few posts DUTOIT .

Can you post a capx? What you describe sounds weird to me. The scroll behavior should work otherwise.

All of those questions can be answered if you read my first few posts DUTOIT .

I did, and that is why I wanted to clarify... Did you use the systems scroll to because it didn't work with other systems? or did you use behaviour which just works, got nothing to do with systems.

A capx example might be better.

Can't post a capx at this point eli0s, too far into development. The events look exactly like I wrote them there, here I'll post a screenshot of em.

The scroll to behavior didn't work with the rest of the game DUTOIT thats why I ended up with move forward and scroll to position every tick.

The forth event is disabled while I was testing the pin behavior that someone mentioned a few posts above. Doesn't matter if I use pin to or set position, the game behaves the same. I'll probably stick with the pin to as I'm guessing it takes a bit less processing power?

I don't get why you're having problems. The setup you describe is straight forward enough, there shouldn't be any problems. The sprite you are pinning is irrelevant and it shouldn't affect in any way the scrolling of the PlayerBox or the system scrollX action.

Here is an example using both ways, apart from a tiny jump which is probably due to a missing tick between the group activation/deactivation, the scrolling is exactly the same.[attachment=0:3iasqmmm][/attachment:3iasqmmm]

If this plays ok in your system then something else is causing the problem.

Perhaps you have other objects with the Scroll to behavior forgotten somewhere? Or a redundant scrolX action hidden in your code? Maybe the PlayerBox is jumping from layer to layer and those layers have different parallax values?

If it doesn't run smoothly, then it's your system that is having trouble maintain steady frame rates.