[Request] Layout control

Discussion and feedback on Construct 2

Post » Tue Aug 02, 2016 11:47 am

Hey, I'm asking the community's scripters, or even @Ashley to try and make this.

What I'm asking is a plugin (or directly in the System tab, if Ashley does it), that would have this:

Actions:
Preload layout
Preload layout (by name)
Preload Object

Condition:
On layout loaded
On layout loaded (by name)
On Object loaded

Expression:
LayoutPreloadProgress that would take an argument Layout Name. Or leave blank if referencing the last Preload launched.
ObjectPreloadProgress that would take an argument Object Name. Or leave blank if referencing the last Preload launched.
LayoutLoaded would return the name of the last loaded layout.
ObjectLoaded would return the name of the last loaded layout.

What would that be useful for? Well, loading screens of course! This has been a common problem with big Construct projects. As soon as a layout or an object is a bit heavy (if it features a lot of animations for exemple) it takes forever to load, and makes the FPS drop a lot or even makes the layout freeze completely. Being able to preload the next layout in background before going to it, or preload an object in background before creating it would solve those problems.
Plus I'm pretty sure this is possible, because Construct already does it to preload the game's musics and sounds at the start of the game, and a lot of games do feature this to make mini games and/or animations as loading screens.
Image
B
33
S
6
G
2
Posts: 220
Reputation: 3,297

Post » Tue Aug 02, 2016 12:01 pm

If you just jump to a loading screen then jump to a big layout, the loading screen should already be displayed for the duration of loading. I didn't think layouts took that long to load anyway - surely it's only a couple of seconds even for a lot of content? Also loading is a pretty intensive and janky process which will tend to freeze whichever way we do it, so it will still hammer the FPS if it's showing progress. It's also easy to misuse this in a really bad way: if you are on a large layout, then you preload another large layout, you can reach up to double the peak memory usage, which causes crashes on low-memory systems. Currently the engine is smart enough when moving between two layouts to ensure the old layout is fully unloaded before loading the next one, ensuring peak memory usage is only the largest of the two layouts and never both at the same time. Any feature where more than one layout can be in memory at once could make this a serious problem.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Tue Aug 02, 2016 3:11 pm

Ashley wrote:If you just jump to a loading screen then jump to a big layout, the loading screen should already be displayed for the duration of loading. I didn't think layouts took that long to load anyway - surely it's only a couple of seconds even for a lot of content? Also loading is a pretty intensive and janky process which will tend to freeze whichever way we do it, so it will still hammer the FPS if it's showing progress. ...

@Ashley I have a short question about this, does the loading affect the multiplayer plugin in any way?
I mean if you for example have 2 connected peers "loading" into a new layout with one running on a slow, potato like PC and the other one loading it way faster.
I'd imagine that it won't but the slow PC would start to sync up information as soon as the layout loaded, so with a delay I guess?
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Post » Tue Aug 02, 2016 3:56 pm

Changing layout has nothing to do with multiplayer. If the host changes layout it needs to send a message to all peers to tell them to change too (otherwise they will sit on the same layout), and after they receive the message and switch layouts themselves, they will receive new data about object positions asynchronously.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Tue Aug 02, 2016 4:00 pm

Ashley wrote:Changing layout has nothing to do with multiplayer. If the host changes layout it needs to send a message to all peers to tell them to change too (otherwise they will sit on the same layout), and after they receive the message and switch layouts themselves, they will receive new data about object positions asynchronously.

That is what I was asking for, thanks for the quick response @Ashley!
(Sorry @skymen for going a little off-topic in here.)
ImageImageImageImage
B
56
S
20
G
76
Posts: 634
Reputation: 43,357

Post » Tue Aug 02, 2016 8:42 pm

Well, in my case, I have a layout that can take up to 10 seconds to load entirely. Which is quite problematic. Plus, my loading screen features an animated "loading...", which appears frozen as soon as the next layout begins loading. I understand that that may be used in bad ways, but that's not an excuse for not having this feature. If someone can't use Construct properly, that's not your fault, but theirs.

Anyway. That would really help to have that kind of feature. It would bring a lot of new possibilities for loading layout creation. So please, really consider the idea. (Even if it's not perfect at first, as long as you can have this done with minimum freeze. FPS drops in loader layouts are not a problem. Constant freeze is one)
Image
B
33
S
6
G
2
Posts: 220
Reputation: 3,297

Post » Wed Aug 03, 2016 12:26 pm

skymen wrote:...I understand that that may be used in bad ways, but that's not an excuse for not having this feature. If someone can't use Construct properly, that's not your fault, but theirs. ...

While I do understand @Ashley 's intentions about this, I have to agree with @skymen . Making a general purpose engine will come with the possibilities that users may use features the way they are not intended. This is not something you can or should try to avoid completely in my opinion. You could always put a warning text in the feature's description or in to the manual.
B
127
S
33
G
17
Posts: 1,551
Reputation: 20,463


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests