[Request] Layout control

0 favourites
  • 7 posts
From the Asset Store
Supports keyboard, mouse and gamepads. Supports several gamepads at once.
  • 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.

  • 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.

  • 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?

  • 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.

  • 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.)

  • 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)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • ...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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)