[suggestion] load the necessary images of layout

  • As we know, C2 engine will load all images from website when open the index.html.

    But the loading-time might not be acceptable. For example, there has a background image for each layout.

    So my request is, the engine might have an option to load the necessary image when go to the layout. It means, there are some AJAX requests for each layout begin, of course.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I second this idea so much!

  • I agreed..

    this will be great for big project.. like RPG.

  • I thought the Layout by Layout loading already did this. Am I missing something?

  • jayderyu

    You could create 2 layouts, put 2 sprite for each layout. Export and run it at browser, see the loading info at console, these 2 images will be loaded (AJAX request) in the beginning.

  • hmm. That's interesting.

    When watching the memory of the game play and especially our larger game. I notice that per layout the memory usage is different. In our highest animated room the memory usage is 250mb and in our first room which has the least our memory usage is closer to 100mb. So memory usage is different. If all the sprites were loaded then our game would likely use about 1000mb at all times. So that's not the case.

    Maybe what is happening is that C2 downloads ALL the assets, but stores them in the offline cache. This would account for for the AJAX to download all the images.

    Also aren't the sprites on export on sprite sheets anyways. So it seems all the sprites have to be downloaded anyways. C2 on spritesheet can't really be selective to what parts of a sprite sheet are transfered. So it seems all the assets are going to get downloaded due to lack of selection. So if you can examine the AJAX call on the sprite image then it sounds like your monitoring a preview.

    While I like the idea of only downloading the assets between layouts when needed and having a loader screen. It just doesn't soudn like it's feasible with the graphics being packed onto a sprite sheet. it sounds like al the sprite sheets need to be downloaded at the beggining. Which does add a lot of download overhead. :|

  • I think this should be taken one step further - I think we should be able to have some manual control over the way the assets are loaded.

    It could be kept simple with two actions and two triggers:

    Action 1: 'load layout assets' - used to download the images of a layout. Works in the background while current layout plays, same as how the loader layout does.

    Action 2: 'preload layout' - used to load images in a layout to the gpu (like the action CC has).

    Trigger 1: 'layout assets loaded'

    Trigger 2: 'layout preloaded' (both triggers take a string so you can tell which layout has been loaded)

    With these actions/triggers, virtually all loading and pauses when switching layouts could be eliminated. Level 2 could download/load images to the gpu when level 1 is playing, or when the player gets to the edge of a level, make a 'loading' layer appear that could be animated, and go to the next layout when it's done.

    I would really like to have this because it would help speed up previewing and initial start up times for players. 99% of the time I'm previewing, it's on one layout. If I could control it so the preview loads that one layout instead of the entire game and manually load the others when I want them, it would be quite a lot faster.

    Similarly, it would also be useful to have 'load object assets'/'preload object'/'object assets loaded'/'object preloaded' to help stop stutters when an object is created for the first time and the game pauses as the images are sent to the gpu. But I think that's not as important as the layout ones.

  • Due to the offline cache, the browser gets to work downloading the entire game right away. If this was disabled, offline support would stop working (which I think is a pretty significant feature, especially for webapp-based platforms like iOS and Android's 'Add to home screen', Firefox OS, the Chrome Web Store, Amazon web apps, etc). So there's no point directing the browser to only download assets half-way through the game - it's already working on that.

    Perhaps the loader layout system could be extended though. If the assets were downloaded in sequential order for each layout, then rather than having just one loader layout, you could go to any layout that has been loaded so far. So for example you could play up to level 3 if it's downloaded that far, but you'd have to wait before playing level 4 if it hasn't downloaded its assets yet.

    Not sure how easy that would be to implement...

  • I've noticed quite a few flash games use a loading animation like the circular gradient. It can be annoying, but at least you get an idea of whats going on.

    Perhaps if there was an option to say what assets get loaded when needed?

  • Just as a feeling from the system. I feel that C2 is awesome, but it's still geared towards smaller games. Our Point and Click game had 250mb usage for one room/layout. On our PC this had apx a 3second load time. Sure this is small; but the game isn't finished. To even get that we had to cut 1/3 of animations. And due to the audio glitch from the load time we had to cut the animations down to 1/2 of the original which had our load time to 2 second.

    because of all of this we had to implemented a fade in/out to hide the fact the game pauses. Now when our game get's bigger this won't be so hidable. Having more input and control would be great. But I do understand Ashley's point of view. C2 isn't an open API it's an entire language environment.

    Though would be really nice to to have a between layout loader.

  • Ashley - I think it should be an option we could choose, because the offline cache is only useful for some games and platforms. For those of us with larger games that aren't targeting the open web or platforms you mentioned, the offline cache is irrelevant because we're not using it since the game is offline anyway. Loading an entire large downloaded game at startup in those circumstances seems really unnecessary, and might limit some of what we can do from the high memory use (imagine something like an rpg with HD assets all being loaded at once). In addition, even if I wanted to use the offline cache for my game - which I don't - 99% of the time I'm running my game is in preview, which would load far faster if C2 had this feature.

    This is one of those scenarios where choosing to have the feature or not causes problems for the people who are on the other side of the fence - which is why having an option to choose would be optimal for all users (something simple like if use offline cache is set to on, all manual memory management events are ignored).

  • jayderyu - I think you're talking about something else - the suggestion in this topic is not to download assets until they're needed. If you switch between layouts, right now that means everything is already downloaded but it still needs to load stuff in to memory. If there is 250mb of images to load in to memory in the next layout, that's just plain and simple a lot of work, and even a native engine is going to take a few seconds to get through that (indeed, that all happens in the browser engine which is actually native code). So that's simply a very large amount of work given the current capabilities of computers.

    @Arima - if your game is already offline (e.g. node-webkit), then there is nothing to download. As above, there may still be pauses between switching layouts not because anything is being downloaded, but simply because loading all the images in to memory can take a moment. And to clarify, layout-by-layout memory management means it does not load the entire game to memory on startup, only the first layout, and when you switch layout it only loads the next layout's images, and so on.

  • Arima - if your game is already offline (e.g. node-webkit), then there is nothing to download. As above, there may still be pauses between switching layouts not because anything is being downloaded, but simply because loading all the images in to memory can take a moment. And to clarify, layout-by-layout memory management means it does not load the entire game to memory on startup, only the first layout, and when you switch layout it only loads the next layout's images, and so on.

    @Ashley - Sorry, I suppose I wasn't clear - I'm aware of what you stated. By "Loading an entire large downloaded game" I wasn't referring to downloading assets from the internet when running a node webkit game, I was talking about a node webkit game that had been downloaded before running, and loading all of the assets from disk at once at the start being unnecessary, increasing startup and preview times, since as I understand it even with layout by layout loading, all files are loaded into ram at the start, they're just not all loaded into VRAM on the GPU at once.

    Also, with the actions I mentioned before, I was theorizing that in addition to the action to preload assets from disk, there could also potentially be an action that could preload stuff to the GPU like CC had, which could be used to eliminate that pause. Perhaps this is better wording:

    Use offline cache: on (same as current, loads or downloads everything at start)

    Use offline cache: off (loads or downloads files of only the first layout)

    Preload layout assets to RAM - downloads from Internet or loads from disk, depending on platform. Happens invisibly behind the scenes

    Preload layout assets to GPU - sends assets of a layout to the GPU. If the files have not been downloaded or loaded from disk yet, they are downloaded/loaded first.

    And triggers for each when they're done.

  • I think the browser keeps the compressed image data in memory, but can flush it out if it runs out of memory and load it from disk again later if things get tight. However if it does not even keep the compressed image data in memory, the pauses between layouts will get even longer, since it not only has to decode the compressed image but also go all the way to disk to load it. Are you sure that's what you want?

    I'm not sure adding actions to manage texture creation is such a good idea - what could you do that's better than layout-by-layout loading without either using even more memory or having janky games which keep loading textures mid-game?

  • I could see where it would be useful for something that's rarely seen like a powerup, or a badge, notifications, etc.

    For example you might have a little in-game tutorial that the player can go back and look at.

    Then again those images would probably take up little memory, or placed in another layout.

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