Proper Programming Methodology

Cipriux - thanks for taking the time to look at it. Would using the timer behavior be easier and have the same result?

Never used, so I don't know.

It doesn't work with timer either. It must be an issue with the "move at 1500*dt" event. I'll try doing what you suggested with setting the end location to snap, but since the camera keeps to the player position, it might look strange. Still no indication as to why yields random results...

I've never used (or seen a need to use) the "else" condition. In that picture what is the point of having the "else" there, would it function the same without it?

— - I actually haven't tried without else; it's really just habit.

I had some problems with not using the else condition in my game. I tried checking if the condition is NOT true but did not get the expected results as with ELSE.

I was using timer and sine behavior to make a sequence of characters behave like a wave, but after 2-3 minutes of waving , some randomness begin to appear. I did not investigate if the problem was the timer or the sine .

A super simplified example to show why you dash further at lower framerate:

Say dt = 10 and dash = 30 and you move 100*dt every tick,

move 100*dt = 1000 px
dash = 30 - 10 = 20
move 100*dt = 1000 px
dash = 20 - 10 = 10
move 100*dt = 1000 px
dash = 10 - 10 = 0
move 100*dt = 1000 px
dashing = false

move 100*dt = 2000 px
dash = 30 - 20 = 10
move 100*dt = 2000 px
dash = 10 - 20 = -10
move 100*dt = 2000 px
dashing = false

if dashing == true
    if dashDistance < 1250*dt
        move forward dashDistance
        set dashing = false
    else
        move forward 1250*dt
        subtract 1250*dt from dashDistance

ramones just to point out....dt is always lower than 0.1 sec (minimum forced FPS is 10)

for 60 FPS dt is — sec

for 20 FPS dt is — sec

Cipriux yes dt could never be 10 or 20, I was just using simple numbers for the sake of example.

— problem, actualy your solution is a great one

ome6a1717   I made a test using ramones solution...and works very well

It works like this:

1.Before dashing calculate the target position target_x

2. if distance from player to target position is greater than dt*speed, than its ok to move using dt*speed

3. else just move the player to target position

If want more explanations, please say so..sorry for my bad english

preview

capx

[EDIT]: use < > keys to "dash", I think the same concept works for dashing at an angle and up, but I not sure.

The red lines represent the player position every tick...

ramones - Interesting. I'll have to try this when I get home.

If this does work, how would I get a less "abrupt" stop and more of a fake "physics push" at the end of the dash?

ome6a1717 maybe use this behaviour to slow down the movement at the end ease transition