• Godot Help
  • Simple scene drops FPS to 58/59 and it shows a lot [3.5.1 stable / GLESS 3]

The game so far is super simple, because I'm testing the main mechanics before starting game development.

I put a couple of images of the debugging of the game to see if it helps.

I ask out of ignorance...

Could the problem be due to the constant movement of the camera follow the player? because if I leave camera static those unwanted stutters don't happen

No, the camera would not cause that. But a moving camera can cause things to happen, such as objects appearing or disappearing, which could have an effect on the performance.

Honestly, the 59 FPS thing is not the problem. Even AAA games will hover around 58 - 62 FPS because it is not perfect, every frame is doing something different so it's not possible for it to be exactly the same.

The issue is probably with your logic being framerate dependent. If you use the delta parameter (the time of the last frame) and make sure all movement code is based on delta, then it doesn't matter the frame rate.

You could even have a game drop from 60 FPS to 45 FPS to 30 FPS and then back to 60 FPS and there will be no slow down. Granted it won't look as smooth, but there will be no difference in the speed of objects or hiccups.

So you might want to double check and make sure you are using delta and timing correctly, having the right things in physics process and/or process and updating correctly.

http://kidscancode.org/godot_recipes/4.x/basics/understanding_delta/

I'm using move_and_slide() in _physics_process and in that case I think it's not necessary to use _delta (I'm not actually using it).

So surely the problem is then in the calculation of the speed of the character or something similar.

Keep investigating!!!

Thanks so much for the help

    I don't think that deltatime has to do with what you describe, but without code and maybe the scene that's just adding to the guess work. Here are some hints for better help with problems: https://docs.godotengine.org/en/latest/getting_started/introduction/learning_new_features.html?highlight=community#learning-with-the-community.

    dandorf I'm using move_and_slide() in _physics_process and in that case I think it's not necessary to use _delta (I'm not actually using it).

    For being independent from frame time, delta must be used to calculate the velocity of an object in _process or _physics_process. move_and_slide() then calculates the outcome of the object's position based on velocity.

    https://docs.godotengine.org/en/latest/classes/class_characterbody3d.html?highlight=move_and_slide#class-characterbody3d-method-move-and-slide

    But the differences here are so small that I doubt there is any visible effect, and I think what we see in the video is not in the engine or in the game, but some other process is causing it.

    I have created a new project to simplify as much as possible and see where the problem is.

    I share what I have:

    Project config:

    World scene:

    Player scene:

    Player gd:

    The tiles and the character are 64x64 px.
    I don't know what more info I can give you, I hope you can help me solve it.

    It's super simple, very few resources and very little code...
    Well, it keeps giving those annoying "jerking" when the FPS drops.

    I don't understand, I'm desperate now.
    Maybe I'm making some noob mistake (what I am, I'm just starting at this), but I can't see it

    Thank you all very much for the help!

    The code looks fine to me. Maybe speed should be a float, but I think it auto converts.

    var speed = 450.0

    What operating system are you using and what monitor resolution and refresh rate? It may be a system/OS issue and not Godot.

    Also, that bounce code won't work. You should probably either check for collision or use an Area2D or ray cast to see if it touched the wall. You might want to remove that code.

    Try changing line number 6 to:
    func _process(_delta):

    See if that changes it. I don't really see any reason that particular code has to be executing in physics step.

    It does because they are calling move_and_slide and that calls into the physics engine.

    I have found that using process is smoother, however can cause issues when the frame rate and physics step are out of sync.

    So yes, that will likely fix the stutter, but may cause other issues down the road depending on how they use the physics engine.

      No, there is nothing wrong with the physics engine or Godot. It's probably just an error on their node setup.

      I see two problems that are likely causing this. One, the camera is a child of the player. This is not how it's supposed to be done.

      The camera should be on the same level as the player (siblings) and you can put a script on the camera that follows the player position.

      Second, the camera process mode is on physics when it should be on idle. Unless the camera itself is colliding with things, I think idle will be best as it syncs to the screen refresh or frame rate rather than the physics step.

      You can additionally click the smoothing enabled on the camera (after you move it outside the player and place the script) and this will further smooth out the movement for any small frame rate drops.

      There is very little reason to increase the physics step in a normal platforming game. If you think you need to do that, it will just be masking a bug, not solving the problem.

      I think I've read Camera2D as a child of KinematicBody2D is the way to make the camera follow the player. Where does it say it shouldn't be used that way?

      The physics process mode for the camera doesn't make any sense though. It should be set to idle.

      @dandorf, sharing your project would make it easier for other to test it and see what's going on.

        berarma I think I've read Camera2D as a child of KinematicBody2D is the way to make the camera follow the player. Where does it say it shouldn't be used that way?

        It doesn't say that anywhere. I just have a lot of experience and that is what I discovered. Maybe for simple tests you can make the camera a child, but in a real game you need to customize the properties of the camera (such as the bounding box, so it doesn't go past the edge of the screen) which you can't do properly if it's a child on the object it's supposed to be following.

        I'm not seeing any issue here, but I have a super computer so I wouldn't expect any frame drops. The code looks fine to me.

        What surprises me is that it also happens to me when I run it on my mobile (android).

        That's why I thought it wasn't my computer issue.
        I thought to make the game for mobile but this error is holding me back 🙁

        I downloaded Godot 4 to try just in case.

        Now I have created the same thing, as simple as possible and with Godot's automatically generated code for a Character2D....

        It keeps doing the same thing to me, it keeps giving those "jumps/stutters" that are very annoying.

        I have come to think that it could be something from my PC, but when I export to Android it has the same behavior, I don't understand anything...

        I have recorded a video with the result in Godot 4. Literally, the code is simply this:

        velocity.x = SPEED
        move_and_slide()

        It can not be much simple.

        (second 42) Notice how near the end of the video it stutters even when the FPS is at 60!!!!!!!!! 🙁 🙁

          dandorf it stutters even when the FPS is at 60

          then it's probably not fps related, though also worth noting that the rendering fps is separate from physics step/fps.

          The mystery deepens. OP have another computer perhaps to test?

            duane I just tried it and I am sometimes going down to 58 and making stutters.

            In your case, use _process, but the same thing happens to me. I tried to change it to _physics_process and it also goes wrong, even worse I think.

            Doesn't it give you problems executing your project?
            It is always stable and there are no stutters???

            Thanks to all for the help.

            It seems that we will never be able to solve it 🙁