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?

  • alspal - 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
    

    total distance: 4000 px

    at half the framerate, dt = 20:

    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
    

    total distance: 6000 px

    -------------

    In your capx (if I've calculated it right):

    at 60 fps you move 1250*1/60 = 20.83px per tick

    22 times

    total distance: 458px

    at 30 fps you move 1250*1/30 = 41.67px per tick

    12 times

    total distance: 500px

    -------------

    So you want to move a fixed distance, say 450px. At the start of the dash set dashDistance = 450. Every tick, move 1250*dt OR dashDistance, whichever is smaller and then subtract the distance moved from dashDistance. So you'll be moving 1250*dt until the last tick and the you just move the remaining distance to make it 450 and don't overshoot.

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)