Background scene loading: Page 2 - Godot Community Forums

Background scene loading

DaveTheCoder

What about the print statements showing the scene loading progress? Those aren't blocked by the scene loading.

I've used multithreading many times in the past, even with single-core processors. If one thread is blocking all the other threads, that defeats the whole point of multithreading.

Megalomaniak

Yeah that's the background thread that is doing the loading, I'm thinking it might be the main thread stalling, waiting for it to finish loading but the main thread would also be the one feeding the renderer...

I'm not saying I'm certain it's this. It's just my gut feeling here.

DaveTheCoder

There are a couple of threading options in Project Settings: Rendering >> Threads Physics >> 2d >> Thread Model

I'm not sure what they do. I tried changing them from Single-Safe to Multi-Threaded, but it didn't make any difference.

Megalomaniak

Without using the provided resource_queue.gd I went through the tutorial linked in the OP and I did get a working loading with a working progressbar(I think it's better than the potential seizure causer sprite in yours).

I can share the project if you want, but again as I said it avoids the issue by simply not using the provided resource_queue.gd script from there, so I don't know if it interests you.

Anyways. Based on the observation from the progressbar, I think it's an issue of the polling and time_max variable combined with the amount of loading stages stemming from loadable files size. So your sprite is probably fine too and works exactly as it should...

DaveTheCoder

I'm interesting in seeing your version of the project. Did you change the value of time_max?

I didn't use resource_queue.gd initially. I only resorted to that when previous attempts at showing a scene-loading progress indicator failed.

Megalomaniak

Yes, to 1. And I switch the function to use usec instead of msec. So micro instead of milli...

https://drive.google.com/file/d/1pq36Axr7VXR8meuaYR164pId2hmRkrmI/view?usp=sharing

Note that the project name is misleading, it was quickly built with the GD Quest TPP template assets and I haven't added a FPS camera mode to it yet.

edit: After reading back my previous post, which I made when I was really tired and about fall asleep... One thing to rectify:

@Megalomaniak said:> I can share the project if you want, but again as I said it avoids the issue by simply not using the provided resource_queue.gd script from there, so I don't know if it interests you.

I don't think the actual issue has anything to do with it, rather it just over-complicated the hunt for the cause. And the issue is just that the scene we are working with here are too small so the progress bar/animation doesn't have enough loading stages to work with.

DaveTheCoder

Thanks.

Megalomaniak

I also wonder if your issue with the progressbar node was that you were using it "wrong". I noticed the documentation page use some custom function to control the progressbar that wasn't implemented in that same tutorial. So obviously it wouldn't have worked.

DaveTheCoder

Which custom function?

The progress bar worked, i.e. the percent of it that was filled was correct, but it was stuck during the scene-loading like the sprite.

Megalomaniak

from the tutorial:


get_node("progress").set_progress(progress)

ProgressBar node has no such method. Nor does TextureProgress node.

As for the progress reported it corresponds to stages passed. For the animation I suspect it only plays a loop for each stage passed and then stops and waits for the next stage to pass.

DaveTheCoder

Which tutorial page is that?

As I recall, the scenes in the FPS tutorial have between 17 and 24 stages of loading. On my Android phone, it takes five to ten seconds for a scene to load. The animation might advance once or twice, but otherwise it's stuck.

Megalomaniak

https://docs.godotengine.org/en/3.2/tutorials/io/background_loading.html

DaveTheCoder

Thanks. I've read so many tutorials lately, my brain is overloaded. :)

I assumed that get_node("progress").set_progress(progress) was just an incomplete example, and that any kind of progress indication could be used.

Megalomaniak

@DaveTheCoder said: As I recall, the scenes in the FPS tutorial have between 17 and 24 stages of loading. On my Android phone, it takes five to ten seconds for a scene to load. The animation might advance once or twice, but otherwise it's stuck.

yeah, but lets assume that the last 13 to 20 of those stages are really small ones that all go quick in succession. Most time might be spent at the first 3, which is why you see the progress from those update fine. Then suddenly the rest are quickly loaded in rapid succession, each time animation gets reset and looks static, then the level is loaded and instanced and the loading screen hidden again...

Megalomaniak

@DaveTheCoder said: I assumed that get_node("progress").set_progress(progress) was just an incomplete example, and that any kind of progress indication could be used.

Well, it says at the very start of the example section:

This example demonstrates how to load a new scene. Consider it in the context of the Singletons (AutoLoad) example.

But I don't see a progress class created in there with such a method either so yeah, who knows where its from. But I feel like the tutorial is not of a very good quality if it doesn't explain where the things it uses come from(or preferably only use things defined in the tutorial). :/

« Previous Page