Background scene loading

DaveTheCoder

I'm attempting to use this tutorial for loading scenes in the background, while displaying an AnimatedSprite as a indication to the user that a scene is loading: https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html#background-loading

It's loading scenes successfully, but the animation doesn't run continuously. It animates once or twice, but is mostly stuck at one image, which defeats its purpose.

Before I tried using an AnimatedSprite, I made two previous attempts. First I tried creating a Label with a progress indication (e.g. "33 %"). Then I tried using a progress bar (TextureProgress). The results were the same: the displayed indicator only updated once or twice, and otherwise was stuck.

Are there any known issues with that tutorial?

Do I need explicit multithreading to solve this?

DaveTheCoder

I implemented the scene loading as a separate thread, using the information in the second half of that tutorial page.

Same results. Scenes load correctly, but the progress animation doesn't run.

Megalomaniak

Does the animation not play at all or it only plays whenever there's actual progress such as when one of the component files finished loading?

DaveTheCoder

The animation does not play at all. I'm printing out the progress of the component stages loading to the Output dock, and that's working.

It's as if multithreading isn't working.

Megalomaniak

Did you set_process(true)? Care to show the code?

DaveTheCoder

set_process(true) is there. If it weren't, _process() wouldn't be getting called, and that's where the scene is added to the tree, and the printing is being done.

The code is messy. I'll try to set up a simpler example that illustrates the problem.

Megalomaniak

Sure, though it might just happen that the simpler example doesn't replicate the issue.

DaveTheCoder

What's the preferred way to show the code? A github repository?

Megalomaniak

If you prefer sure. Could also make a gist and link in here. Should get embedded.

DaveTheCoder

Okay. I put a tarball on Dropbox: https://www.dropbox.com/s/hfditsapv8ngla5/FPS%20tutorial.tar.gz?dl=0

It's basically the FPS tutorial, which I have been using as a base for experimenting.

Scene_Loader.gd is the scene-loading script. Its function load_new_scene_interactively() is called to load a new scene.

resource_queue.gd is the class for loading a scene in a separate thread.

LoadingSprite.tscn is the AnimatedSprite that's displayed during scene loading.

When running the game from the editor on my computer, it only takes a second or two to load a scene, so the issue isn't very noticeable. But when I export the game to my Android phone, it takes five to ten seconds to load a scene, so the stuck animation is more of a problem.

Megalomaniak

You might want to avoid bundling the audio files the custom eula applies to...

edit: neveer mind, on closer inspection I do recognize the license and it allows for this so it should be fine. :)

edit: 2 so I do see the loading sprite asset "blink". Seems to work fine on my end with godot 3.2.1. Might be an issue with the specific godot version?

DaveTheCoder

~~Do you mean I shouldn't have them in a .tar.gz that's linked here?~~

I'll be careful about that if I upload assets whose license makes that an issue.

Megalomaniak

Yeah, thats what I mean, but depending on the licensing terms of course.

So I increased the fps of the animation and now see the issue, just ~~leaded~~ loaded too fast indeed to notice it before.

I wonder if it stops because it's part of the nodes in the current_scene that is in process of removal... :tongue:

DaveTheCoder

SceneLoader is AutoLoad-ed in Project Settings, so it's a child of root.

It me a while to figure out that it needed to be outside of the scenes. :)

LoadingSprite is a child of SceneLoader.

While the game is running, even when switching scenes, they both remain visible in the Scene dock / Remote tab.

DaveTheCoder

Megalomaniak, did you give up? ;)

Megalomaniak

Wasn't sure based on your previous post if you had figured it out yourself.

DaveTheCoder

Sorry for the lack of clarity. I had made SceneLoader a child of root before my initial post. I'm out of ideas on figuring this out. :)

Megalomaniak

It might be just a placebo but I did feel like the loading animation was running a bit smoother after I switched the pause mode to process. I doubt that it really did anything though.

I still saw it stop right before the level loaded though and I suspect it has something to do with that. The animation and the loading probably run in the same thread or at least on the same core so something about the loading probably stalls the animation playback.

Maybe the solution is not to deal with the AnimatedSprite properties but the methods play() and stop() and use call_deferred()?

DaveTheCoder

The animation and the loading probably run in the same thread or at least on the same core so something about the loading probably stalls the animation playback.

The loading is explicitly in a separate thread (resource_queue.gd). If that blocks the animation, isn't that a bug with Godot's multithreading?

Maybe the solution is not to deal with the AnimatedSprite properties but the methods play() and stop() and use call_deferred()?

I'll look at that. Although before trying the AnimatedSprite, I tried a simple Label to display the percentage complete, and I also tried a TextureProgress.

Thanks for your help.

Megalomaniak

If I'm not mistaken its the OS handling the actual allocating of cores so while the scene loading might be happening in a separate thread it might still be queued on the same core. That's what I was trying to refer to.

Most(do we count AMD FX bulldoser arch?) every modern x86 processor implements a form of simultaneous multithreading(simply referred to as SMD on AMD and what is called HyperThreading on intel).