Help Needed with Stuttering Issue in Mobile Game Godot Course (Section 35)

Other Courses Ask
#1

Hi everyone,

I’m currently working through the Mobile Game Godot Course and I’ve hit a snag in Section 35. I have installed the debug APK on my phone, but I’m experiencing significant stuttering issues with the app.

The stuttering is visible enough to cause me a bit of a headache, but it is also intermittent—it comes and goes in ~5 second waves. I thought it could be related to instancing objects, but screen is tall enough that I can see the instancing. Additionally, nothing came up when I looked at the profiling tool.

I’ve tried reinstalling the APK several times, but the problem persists. I don’t believe the issue is with my phone, as its powerful enough to run more intensive applications without any problems.

Any help or suggestions would be greatly appreciated!

Thanks in advance!

#2

Hi again WT; I’ll do what I can.

First of all, very important, was everything ok before starting lecture 35 (Accelerometer Input)? Reason being, if so, that drastically limits where the problem is likely to be. If you aren’t sure, try commenting or reverting the Lec35 changes and testing again to see if the issue persists. If it does persist even with that code commented out, take the same approach with other blocks of code and see if you can narrow down where the problem appears to come from. This is an excellent debugging exercise by the way; this strategy will help you in future projects!

Second, what you are describing sounds like stutter, but please be aware that (at least in the context of Godot) “stutter,” “jitter” and “input lag” are actually not interchangeable terms. This is a good thing, as it means we have a clear term for identifying and tackling each and any of those issues! Please have a thorough, detailed look at this page and see what best describes what you’re seeing. Feel free to try any of the proposed solutions as well (among the docs pages, this one is a shining star in my opinion):

Let’s start with those things for now; let me know your findings and we can go from there.

#3

Hi again BH67,

Thank you for the reply. I thought I would surprise everyone with another ask post right after the last one.

I did read the linked article and compared this against some footage I screen recorded (could not find a way to attach the mp4 file to this post unfortunately). It is hard to say because I would describe the platforms as “shaking” when the issue occurs, but it is not constant. I think we should stick to stuttering as the issue for the moment.

As for commenting out the lecture’s changes and testing a reverted build, I will do this, but it may take me some time due to personal commitments at the moment. I agree that this is a good technique to debug the code and hopefully, figures cross, the problem is in there.

1 Like
#4

No problem, take your time. I’m not going anywhere =)

Yes, that’s deliberate for bandwidth reasons. The only options you would have are to convert to a .gif (which is probably good enough for this purpose despite the loss in video quality), or post it to a video hosting site like youtube and add a link to it here.

Also, forgot to ask - the shaking is only happening on actual mobile hardware, and not with an emulator or a local execution within Godot, is that correct?

#5

I have only seen this on the mobile hardware. Within Godot it is running very smoothly, and I cannot comment on the emulator as I stopped just before that lecture (it is the next one).

I did try 3 conversion tools online, unfortunately the lost of detail means the issue cannot be seen in any of the processed files. There was a attempt there though.

1 Like
#6

Ok, sounds good. Since I won’t be able to reproduce the problem on my end, I’ll be relying on whatever you find from the isolation test we talked about earlier.

#7

Hi BH67,

I managed to get some testing done: I setup a project using the code + scenes from Lecture 27 (end of the initial Mobile Gameplay Section) and I am still seeing the stuttering.

It was pretty hard to do a good test as the platforms are random in the x plane and, at this point, we don’t have any mobile control of the player. So, I did a quick edit to the level gen script so the platforms would line up vertically and thus the player would have platforms lined up to jump on. From this I saw there was a gap between the periods of stuttering and timed it out to every 5.6-6.3 secs.

I also setup the same scene with the player only bouncing on one plaftform (no continuous vertical movement/ parllax scrolling) and saw the same stuttering behaviour as described above complete with the same timings

Does this help narrow down what the issue could be? Should I go even further back in the lectures?

#8

Excellent, and I can see you got creative with designing your tests. That’s a great skill to develop =)

Divide and conquer testing is one of the best things you can do in general, because regardless of the outcome of that type of test, it tells you something that can help narrow things down. In this case, what appears to be an inconclusive test actually suggests that the problem likely isn’t caused by any of your code (not guaranteed, but at this point, extremely likely). The project is almost as barebones as it could be, and that has had what sounds like no impact at all. Chances are, even if all you had was the main menu with a bit of animation on the button, you would still see the same problem. What this means is, unless you feel like stripping even more stuff out (and you can certainly try that, I’m not being sarcastic) to raise our certainty further, we can turn our attention to project settings, and by extension, the stuff in that link I posted last week.

Furthermore, because your desktop performance is fine and most other students don’t have this same problem, it’s now a very safe bet that this is all caused by some kind of quirk on your specific phone. For that reason, there’s a decent chance this is not fixable, but there are certainly a number of things to try:

I suppose the first thing we should have attempted in hindsight is to change the renderer from Mobile to Compatibility. When you do this, you should also go to the General tab in Project Settings and set Rendering–>Renderer–>Rendering Method.mobile to gl_compatibility. It seems these properties override whatever you set in that dropdown menu in the top right of the Editor, so always double-check that they are what you want them to be.

As another test, map a button to a new input and create a counter variable that starts at, say, 25. When the input is pressed, have this counter variable increment by 5 (so that it starts at 30), then write Engine.max_fps = counter. That’s the basic idea, modify as you see fit, but you can probably already see that this will allow you to quickly test different max_fps values to see if there’s some kind of correlation here. Given how fundamental the test project is at the moment, you’ll probably need to keep track of counter's value yourself as you increment it.

In the General tab of the project settings, you can also try any or all of these:

  • Set Display–>Window–>V-Sync–>VSync Mode to Disabled
  • Set Display–>Window–>Size–>Mode to Exclusive Fullscreen
  • Increase Physics–>Common–>Physics Ticks Per Second. Keep this to multiples of 60.
  • Tinker with Physics–>Common–>Physics Jitter Fix. This should be kept between 0 and 2 inclusive, and I would include both in the set of values you try, just to see what happens. You will also need to enable Advanced Settings in the top right of the Project Settings window in order to see this.

If none of that makes a dent, then I’m afraid I’m out of ideas, so let’s hope something in there sticks! Do let me know either way, as I learn from these questions too ^v^

#9

Hi BH67,

I started off with the fps counter test:

Still used the Mobile Rendering: I set up two labels to display to the actual FPS (from Engine.get_frames_per_second()) and the counter value that I using to set Engine.max_fps. On the computer I was getting a steady maximum 165 FPS. On the mobile the maximum FPS was 57-59, but it would drop to 45-47 when the stuttering occurred. When I was testing by increasing the fps in increments, it was a stead fps until I got over that 45 mark, in which case we would get the intermittent drop to 45 fps every 5-6 seconds (in my example I was at a set valve of 55 fps when I noticed this).

I then tried switching the rendering method.mobile to gl_compatibility and the shuttering issue was gone. The mobile app was running at a steady 60 fps. I even tried going back to my ‘lastest’ build I had backed up got the same result when I switched the renderer (confirmed with my new fps label I remade in the project.

I will continue test the mobile build a bit more but hopefully we have found the solution!

In case this is the final message on this topic, I want to thank you for your help. I have learnt a good deal working through the problem with your guidance and knowledge keeping the testing on track. It is extremely appreciated.

1 Like
#10

That’s quite interesting - it definitely appears to be hanging on something, hogging processing cycles, but again, likely not anything you coded yourself. So, in this case, limiting your max fps to 45 is one not-so-ideal way to fix the problem (it’s a project setting, just like the others, but I knew the dynamic test would be more useful to you). There are worse things than 45fps!

Possibly not surprising that the Compatibility renderer did the trick in the end, as Godot 3’s rendering (which is more or less what that is) is tried and true while Godot 4’s still needs time to mature. Even though it’s been, what, a year? It’s an unfathomable undertaking to make something like that work the way it should, but this is why the Compatibility renderer is still included in the engine!

I’m glad you got so much out of it; have fun with the project! ^v^

#11

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

Privacy & Terms