How not to depend on delta in update()

was setting jump using delta as follows: when i press the jump button, a timmer float variable is trigger. All I do is timer += delta; and then when the jump stops I reset timer to zero.
This works fine, but of course if I change the frame rate to 30 instead of 60, no delta es different and my jump is much higher. Even if I do time += 0.1, the addition still depends on the refresh rate and my jump changes.
So how do you deal with transformations like a jump or anything else without depending on delta.
Does that question make any sense?


Is it OK to calculate delta according to your own frame rate?

 update(dt) {
        let my_dt = (1 /;

I don’t think so.
As far as i know, we have an update method with a delta argument that corresponds to the fps. So 60 fps will run the delta variable 60 times in a sec.

So the problem is that even with what you suggest, that variable will be executed as many times as the update method runs per second. Therefore, if I use to add movement in x, the movement will be slower or faster depending on the fps.

What I want is the movement to be the same no matter the fps. I.e, make the logic of the game independent of the drawing renders per second.

@rudiHammad Then you can schedule update for 1/60 only

    schedule(SEL_SCHEDULE(&HelloWorld::customUpdate), 1/60);
void HelloWorld::customUpdate(float dt) {
    log("customUpdate called");

That might actually work. A custom update and then dividing by the frame rate. Thanks.
Is that how its is done usually? Or are 60 fps always solid so we don’t have to worry about it (specially for pc)? I read threads from users having mobils refreshing at different frame rates, so depending on the device the gun would run slower or faster.

Basically i never rely on dt for such things (for ex. Jump), you should use physics for that (apply force/impulse)

what about games that don’t rely on physics? say a space shooter where you don’t really need physics because all you do is find an intersection between the bullet and the enemy. The bullet might travel at += 10 * dt, so the more refresh rate, the faster it goes which is not good. Wouln’t you apply there a custom shedule as mentioned above?

In that case also i will not go with update method, i might implement through runAction so that refresh-rate wont effect the output. o/w you can schedule with fix fps as i mentioned above.

I see. One last question before I close the thread. You mentioned actions which is actually one of the reasons I made this thread. As far as I know, once you create an action you can’ t modify its properties can you? so if you use a MoveBy action to make the bullet move, say you pick a “power up” in the game that make the bullet move faster. Can you modify the speed of that action? because I can’t see any property in the documentation allowing that. Same with the JumpBy. It doesn’t seem that you can modify the height for instance once you create the JumpBy action, right?

No you cannot. You can stop current action and assigned new one based on new properties.
And thats why physics engine exists to make our life easier.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.