• Godot Help

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

cybereality

It is a very simple game.

My PC has the following characteristics:

SSD hard drive and 64 bits OS.

Anyway, the same thing happens to me on my Android phone. I don't think it's a PC problem.

I put a test video of the game and you will see how it jerks... because the FPS drops from 60 to 58/59 from time to time (I have seen it in the debugger)

https://www.youtube.com/watch?v=i1NTetyYbEo

in the second 4 approx of the video you can see what I comment

      dandorf ... from 60 to 58/59 ..

      That's insignificant. From 60 to 59 could just be a rounding error.

          Pixophir That's what I thought, that it would be something insignificant, but it is too noticeable in the game... because it jerks every time it drops 1 or 2 FPS.

            You can test with V-Sync off, but the FPS is never going to be exactly one number. It will fluctuate and that is normal.

            Without V-Sync it has very high FPS (700 approx) but it still jerks.

            I have verified that with the fixed camera this is much less noticeable. But I'm interested in the camera follow you all the time.

              Then it is most probably something different from the mere frame rate, or even the flow of the game. Maybe a virus checker or some such ... but I can just guess without more information.

              dandorf Without V-Sync it has very high FPS (700 approx) but it still jerks.

              This is why for debugging purposes graphing the frametime is better. Also see what is going on in process and physics on the low rate/slow frames if you can. It might be something on the cpu side and not gpu that is bottlenecking/taking long on those frames.

                Could be something with loading files. DIsk reads can cause hiccups. Probably not GPU related if you get 700 FPS without VSync.

                Object creation or deletion can also cause hiccups.

                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.