How do I keep a layout running while the next one is loading

Hey, at the moment, to load the heaviest layouts, I use another layout that displays a text and an animation while the next layout is loading. However, my problem is that everything stops as soon as the next layout starts loading, including the animation. That gives the layout a froze effect, and that's quite problematic. So is there a way to have the layout continue to run as long as the next layout is not fully loaded yet?

I don't think this is currently possible.

offline-loading-screen-between-each-layout_p968526?#p968526

https://www.scirra.com/tutorials/4832/h ... en-layouts

Well thanks. I'll try to make something like this. However, it's still quite problematic. Can't we have a feature like "preload layout" and when the layout is fully loaded, have an event "On layout loaded". I may ask this as a plugin request.

Why would a player need to keep playing while the next level is loading?

Well, imagine this:

I have a loading screen that has an animation in it or even a minigame, or anything to keep the player focused.

Right now, I can't have this, because you cannot preload another layout in background. So to have this you have to "simulate" a loading screen, make it do what you want, and then go to another layout. However, this is problematic, because, if you have a layout that needs a lot of memory, the current layout completely freezes while the other layout loads, and when it finally shows, you have a quite big FPS drop.

Having a way to preload another layout before going to it would fix those problems.

In my case, sometimes, a layout can take up to 10 seconds to load properly.

There may be a way, but it is a bit more cumbersome. In addition to using the method described by backendfreak, you can have by default all your sprites on your layout mimimalistic or blank/low resolution. Then after you load into the layout. but while your layout is still obscured by the loading overlay, use the sprite objects load image from URL to replace the fast loading sprites with your actual sprites. Your overlay should be able to run as this is happening, so you can set up your minigame first, or show progress.

An additional benefit is you can use on (final) image loaded to start your actual layout, which is better than just waiting an arbritraty amount of seconds.

Yeah, that may do the trick, but is indeed a lot more complicated. But, having placeholders for big objects and replace them in my custom loading screen is a good idea. However, that may make the level design a bit more complicated, as big object tend to have more animations, or bigger resolutions. And if they do have a lot of animations, you may want to have multiple instances of this object and each one running a different animation on start. It would take a bit of coding to have this done along with the placeholder. But that's very complicated.

I see two options here:

1. As described in my tutorial mentioned above. Basically you show loading screen at the end of the first layout and you hide it once everything is loaded/stable on the second layout. It doesn't speed up the loading process but at least you get rid of that "freeze" feeling.

2. C2 engine clears the memory while switching between layouts, but it keeps the objects which are used both in the layout you are now and the one you are switching to. So basically all common objects remain in the memory and there is no need for the engine to reload them. You can use this fact and load the assets you need in the next layout just before switching to another layout (or during gameplay... up to you).

I think you don't need to place the second layout assets in your first layout. Never tried it myself but simply spawning those objects from the code should do the job.

There's another trick here. Keep in mind that C2 engine does not load objects which are outside visible area, so spawning an object at position -9999, -9999 won't work. Also invisible objects are not being rendered. So you need to do some kind of dirty trick like:

a) spawn object at any position

b) set it's opacity to 1 (almost invisible)

c) set it's position to overlap visible area (it doesn't have to be the middle of the screen, it can be partially visible somewhere in the corner)

d) wait 0.017s (that's the duration of 1 tick), not sure if this's gonna be needed but I believe it will to force the engine to load/render the asset

e) set it's position somewere far away

Might look complex but if you prepare good generic code then it's just a matter to setup some lines in event sheet for each layout.

Well, thanks. Your second idea is really good. What's eating up most of my memory is a screen object that displays a lot of different animations.

I'll see if I can somehow preload it anywhere, and make it global so it is not deleted. That may not be a good idea though. I'll try what you said, and let you know.

I don't understand. Why does a player need to be playing a minigame, for 10 seconds, while the next level loads?

Regardless of there being a minigame or not, when loading significant amounts of information into memory at once, the screen can freeze for a period of time with no feedback at all for the user, not even a loading animation. This is bad design, as it can lead the user to assume the program has crashed.

Even if for a short period of a few seconds, it can be disconcerting. For longer periods, the user may even force quit.

Anyways, IMO minigames during loading screens are the greatest thing ever. Especially for games that have relatively more instances cases of loading during any given session. For me the first time I encountered it was on the PS2 version of Okami, and it really made a positive impression on me.

skymen - It could be wasteful of memory to keep a heavy image like that on every layout and not use it. But that really depends on your project and if you are pushing your limits. Using the techniques described, it would be better to change to an intermediate loading layout (thus unloading the previous one from memory), then load the heavy image by request, then switch to the new layout. The intermediate layout could have your loading animation or minigame.

If people are that impatient then they shouldn't be playing video games.

Well, there are a few possibilities. It really depends on the game.

A few exemples can be Dragon Ball Z Budokai Tenkaishi 3 where you could mash a button to do an action while the game was loading. Like having Goku eat loads of food, Vegeta doing pushups, or Gohan extract excalibur from the ground.

You could also have the player see a little animated loading, like the one present in the simpson game, where you would have Itchy and Scratchy hitting each other all over the screen. Or even have some hidden things that would reveal things about the game. Let's say, each time a level loaded, you had a really tiny sublevel, where you would have to move your mouse through a pattern before the loading ends so it can reach a key, some gold, or some easter egg and/or information about the game.

The real question, is not "why do you need that?" but more "why can't you have that". The goal of softwares like Construct relies on making something that was first a bit hard, becoming simple, while keeping its freedom. So for every tiny little thing that can be done using code, you should be able to do the same using Construct. Plus Construct is waaay past the state where there was still big features left to have done. The only thing that has been done through the Construct releases are mostly bugfixes, fixing compatibility issues or changing some features. So adding this kind of features, the ones that has been requested by the community is the only thing left Construct may want to add.

oosyrag Yeah, I know, I'll try to have the object created in the loading screen at 1 opacity, like backendfreak told me and see how it went.

You can also just put a plain tiledbackground to cover it. I'm pretty sure sprites loaded with request from URL are loaded into memory regardless of if they are rendered or not. I recall seeing that documented somewhere... can dig a little to confirm.

Well, that's not sure, because, in some cases, what is not rendered is not loaded into memory. I prefer being sure to have it rendered as my object is pretty dark and my background plain dark.