Ashley
That's the wrong solution, and uses an extremely coarse measurement anyway. You probably should use something like requestIdleCallback instead.
Okay. I'll look that up.
Besides in the C3 runtime layout loading is now asynchronous so may not jank the game any more while loading. Also the whole idea of preloading an entire other layout will spike the memory usage high, significantly increasing the risk of out-of-memory crashes... it kind of defeats the point of the layout-by-layout memory management that aims to keep peak memory usage low.
Well, I'm not sure about that. But I surely haven't encountered that in c2runtime on Construct 3 at least.
Although, aside from the conventional usage of that addon, there is an exclusive use for that addon that the normal layout-by-layout loading can't do.
Imagine having 100 Spriter Character objects / 100 Sprite objects.
You have to preload only 10 of those characters per game. As you only use 10 Players per battle match.
You can't do that with normal layout-by-layout loading as you will have to load image memory that isn't even used.
With this, it ensures that images that are only needed are the ones only loaded.
Plus, you can add custom initializations per layout.
I'm not sure why this needs to have anything to do with loadingprogress either - why not just give the plugin its own expression? The more you hack in to the runtime code, the more brittle it is in the face of future changes. The best architecture is to keep as much code as possible entirely independent of the runtime.
It needs to. For example, you are on the loader layout. Before going to the main layout, you need to preload the main layout to only load the images needed and also for some custom initializations. But, you need to wait for the Construct Engine to load first or at least finish.
I hope that explains it all.