# Move player smoothly X pixels at a time?

1 Favourites
• 18 posts
• Probably quite self-explanatory from the title.

I'd like to move the player 32 pixels on each keypress, but move the him smoothly pixel by pixel. In other words, slide 32 pixels at a time.

Thanks.

• check lerp()

• Hey JayH

you can try this. The disadvantage of pixel-precise movement is that only certain speed values can be chosen.

EDIT:

I have added two decimal numbers as possible speed values. Since decimal numbers can not be calculated 100% exactly,

the final result is not exactly 0. Therefore the margin of 0.01 in the conditions and round up of the player co-ordinates.

This 4-Directions movement should be well suited for games like the old Pokemon editions.

• Thanks guys, I'll check out Lerp today as it seems the most specific to my needs, I'll have to use dt too for the movement between, not specifically 1 pixel at a time.

• yep, lerp() is what you need. It is a math function used in basically in all/many games/engines.

• yep, lerp() is what you need. It is a math function used in basically in all/many games/engines.

Darn it, my posts here keep disappearing!

Ok, I've gone through lerp, but I'm still stuck.

I've tried this:

obj_Player = lerp (obj_Player.X, obj_Player.X + 32, dt)

But it's too quick to know.

I've tried this:

obj_Player.X = lerp (obj_Player.X, obj_Player.X + 32, 60*dt)

and

obj_Player.X = lerp (obj_Player.X, obj_Player.X + 32, 60/dt)

I've also tried this from the below blog post:

obj_Player/X = lerp (obj_Player.X, obj_Player.X + 32, 1 - 0.5 ^dt)

https://www.construct.net/gb/blogs/ashl ... a-time-924

I also checked out this post:

how-do-i-lerp-with-dt_t129150

• But whats the problem u r getting?

Its moving too quickly or it isnt smooth/moving?

Care to print the event where you move/use it?

• It's moving smoothly, but not in 12 pixel segments/blocks. It looks like it should work, but doesn't.

Here's a screenshot to make it clearer:

https://db.tt/fnUP8fU4BP

• This can not work.

Here's an example of lerp: lerp (10, 20, 0.5) = 15, so 50% between 10 and 20. The last value in the lerp function must be between 0 and 1 (0% -100%).

When you use "Player.X + 32", you run after yourself, because if the player moves 10 pixels, the second value increases by 10 too.

You would have to set a target value beforehand: lerp (Player.X, DestinationX, var). The last variable would then have to increment â€žslowlyâ€œ from 0 to 1 to move OVER TIME from Point A to Point B.

But your event runs only one tick when you use on press the button or he moves infinitely when you hold down the button.

That is so complicated and inaccurate. I do not know if anyone has a better idea to use lerp right here, but I recommend you just try the code from my screenshot or get it here for C3:

https://1drv.ms/u/s!Ap_-qxoGKbDcg0v3iWcZn69XQycl

• I see.

When you tried 1 - 0.5 ^dt it was fast too? As fast as 60*dt?

Considering you want 12 px and the distance to cover is 32, i would say at first, maybe 1 - 0.25^dt

Also, check this out, great explanation: https://answers.unity.com/questions/237 ... -work.html

(mb if couldnt post this here, but as others usually talks about other engines...)

• ## Try Construct 3

Develop games in your browser. Powerful, performant & highly capable.

Construct 3 users don't see these ads
• I tend to use the rex_moveto plugin for something like this, it should accomplish what you want to move 32 pixels to right on a key press. https://c2rexplugins.weebly.com/rex_moveto.html

As mentioned above your code is fine except you need to define player.x+32 as a variable beforehand as the player.x changes while lerp is running.

• Thanks Kriand, I guess it's a tricky one then.

I really need my events to avoid frame dependence, so I have to try something with dt. I was hoping for a neat and tidy method without creating lines of code and variables for something that appeared so plain that could be in an equation. Maybe Lerp just isn't the right method, unless someone can offer any other help.

Cassianno, sorry, no that makes no difference, we've still got movement, but without a step of 12 pixels, I understand where Kriand is coming from.

Plinkie, I look into the viarable for the player.

I have more research to do!

• if i am not mistaken, it should suffice to change the last part of my example as follows in order to achieve framerate independence:

• Thanks Kriand, I'll take a look.

Edit: I've now tried the example you gave and both seem to work ok. The dt one runs, but like with most dt stuff I can't verify if it's truly working. Not the most elegant solution, but a welcomed working one all the same, thanks.

• Hey JayH

Here you can test if dt works. If you have a supercomputer, you have to increase the particle number even further <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I am sure, as soon as a value is multiplied by dt, it is framerate independent. No reason to worry.

The only exception would be "Every dt seconds", where it reverses into dependency.

https://1drv.ms/u/s!Ap_-qxoGKbDcg0zxCpBkPj6Vc1Hj