[suggestion] load the necessary images of layout

Sorry I haven't managed to make this clear. Here's an example:

Current scenario, with C2 as is: on preview or double-clicking a node webkit exe, NW or the browser starts up and loads all of the files from disk into memory, decompresses the needed ones for the first layout, sends them to the graphics card and starts the game. For this example, let's say with this process the game takes 1 minute to load.

Suggested scenario: on preview or double-clicking a node webkit exe, NW or the browser starts up and loads the files for the first layout from disk into memory, decompresses them, sends them to the graphics card and starts the game. This will result in the game loading in a fraction of the time.

With no interaction, the game will not load any other layout's images, from disk or into VRAM, and upon switching layouts, the game will pause as it loads the images from disk, decompresses them and sends them to the gpu. While that at first seems like it's worse, it's actually better when used with the actions I suggested, which results in this:

• On preview or double-clicking a node webkit exe, NW or the browser starts up and loads the files for the first layout from disk into memory, decompresses them, and sends them to the graphics card. This starts the game much quicker than loading everything at the start.

• First layout starts with a company logo and maybe an intro sequence before showing title screen. At the start of this layout, the action 'preload layout images to ram: "Level 1" is run. While the user watches the logo/intro and messes with the settings in the title, the game loads level 1's images from disk. This is basically what C2 does automatically once with the loader layout, except in this case it doesn't load the whole rest of the game - just the layout specified. When complete, this trigger event runs:

-> on finished loading images to ram: "Level 1"

   -action: preload layout images to VRAM: "Level 1"

Now C2 loads level 1's images to VRAM, while the user continues through the title layout. When it's done:

-> on finished loading images to VRAM: "Level 1"

   - action: set variable level1loaded to true

Now, when the player clicks new game and goes to level 1's layout, there will be no loading times at all, not to get the files from disk or into VRAM.

If the player clicks new game before the loading is complete:

->If clicked on new game

Level1loaded is false

• action: show layer: "Loading"

-> on finished loading images to VRAM: "Level 1"

If layer "Loading" is visible

• action: go to layout "Level 1"

At the start of layout "Level 1"

• action: preload layout images to ram: "Level 2"

...and level 2 loads in the background as the player plays level 1.

Using this method, all loading aside from the initial layout can be hidden, as long as the player doesn't tear through the startup screen, and even if they do, as I showed in my example, then an animated loading screen can be shown, and this would solve the problem Jayderyu was having with the music pausing as well when the game pauses for too long.

The result: even the most impatient player will be playing level 1 long before the game would have loaded otherwise if the entire game needed to be loaded. This would help a lot also for online games, getting them into the action quicker since downloading is slower. Maybe an extra action could be made: 'create offline cache' which would then download everything that hasn't already loaded. This way we could have both reduced start times and create an offline cache, the best of both worlds for the platforms that would use offline cache.

It would also benefit preview times tremendously, as it would only load the single layout, instead of the whole game, and I don't know about others, but most of the times I preview it's to test one layout. Larger games do start taking a while to load without something like this.

Again, this could be an option, so those who don't want or need to use it don't have to, and can keep using C2 as it currently is. It's one of the features I want most, actually, because of the reduced preview times.

Arima: +1

I dislike when people do the +1 thing, but i don't have anything to add, and i need to express my support. Kudos on the detailed post and persistence.

Ashley

Since the key of initial loading is file "offline.appcache". It might be better to have an exported option in C2 editor which could turn on/off the file "offline.appcache" (have it or not, maybe).

The action of loading asserts from server manually is another issue. I like it, too.

+1 on Arima's last comment

+1 on Arima

+1 Arima. This should be here from the beggining.

Arima - your example could double the peak texture memory usage. Take your example but going from level 1 to level 2 instead, which use different image sets (e.g. level 1 is "desert" world, level 2 is "ice" world).

Currently the C2 engine efficiently manages the peak memory usage like this. When switching layout:

• the engine stops running
• any images used on level 1 but not used on level 2 are released
• then any images used on level 2 but not used on level 1 are loaded
• then level 2 begins running

Therefore the peak memory usage is never higher than what level 1 or level 2 would use by themselves. This pretty much can only happen because the engine stops running while this happens, so it doesn't suddenly need an image after releasing it.

If you can load the next layout's images before the current layout finishes, you end up with a pattern like this:

• level 1's images are in memory
• you request to load level 2's images while level 1 keeps running
• briefly, both level 1 and level 2's images are in memory - this could be up to double the memory usage
• when switching to level 2, level 1's images are released and memory usage goes back down

For any games close to the memory limit of the system, this would probably crash the game when it changes layout.

For previewing, it's a different matter really. Maybe we could do something to speed it up, but it's a little complicated: you can't create objects from other layouts or go to a different layout until the rest of the game finishes loading. That could result in some weird preview issues. An advantage of loading the entire game in preview mode is you can jump to any layout at any time.

Ashley - I'm aware of that situation. If a person was making a game where the intro/title screen was 50 mb and level 1 was 100 mb, there would be no problem having them both on a 512 mb card. Knowing what we could do would be made easier with 'remaining VRAM' or 'total system VRAM' expressions, if they're possible.

Another example is if someone was making a very resource intensive game, they could do this instead:

Game starts, intro_and_main_menu layout runs.

At start of layout, load images from disk to ram: "loading" and "Level 1"

C2 now has the "intro_and_main_menu" "loading" and "Level 1" layouts in RAM and "intro_and_main_menu" in VRAM.

Upon clicking new game, go to layout "Loading"

C2 then dumps all the textures from the "intro_and_main_menu" layout from VRAM, loads the very small amount of textures on the "loading" layout and runs it.

On start of layout: load images to VRAM: "Level 1"

C2 now has both layouts "loading" and "Level 1" in VRAM. This happens smoothly as the loading layout can keep running, being animated and there's no concern of the music stopping from it taking so long to move the textures to the gpu. The loading layout is small enough that it's not a concern having them both in VRAM at the same time.

On textures loaded to VRAM: "Level 1", go to layout "Level 1"

C2 dumps "loading" layout's textures. Level 1's textures are already in VRAM, it starts instantly.

This way we get flexibility and control over how we want it to run.

As for the pausing problem when creating objects from other layouts that haven't been loaded yet, we could just do the same for objects with 'load object files into ram' and 'load object files into VRAM' actions with triggers for when they're finished.

Having 'unload layout textures from VRAM', 'unload object textures from VRAM' and 'unload all unused textures from VRAM' actions would be useful as well.

I can understand why you might be reluctant to incorporate this at the risk of confusing less experienced users, but that's why it could be an advanced option so the more experienced users can use it instead. Professional games use loading screens in this manner quite often, it would be very useful for us to be able to do the same if we want to. While C2's memory management as it is is fine for many games, it isn't optimal for all types of games, and this way we could choose how we want it to run.

— am an avid supporter of this suggestion! The offline.appache feature makes my life a living hell whenever I am trying to edit and update my game. I fully support it being an option.

we need MANUAL control of what assets to load and which ones to flush out, apart from the current autoloading mode. This is essential for exe & mobile exporting. More people are nowadays using C2 for making exe games than html online games

+1 arima

I'm not a programmer but I'd imagine that Ashley would have to write a completely new loader, that would request assets sequentially and not too fast - one by one, or part by part, but with some breaks, and somehow be integrated in to the event sheet loop ( and I don't mean events, but just making sure the game will run while and loadding assets wont take much away from games fps). It would be definitely very good to have.

I can understand why you might be reluctant to incorporate this at the risk of confusing less experienced users, but that's why it could be an advanced option so the more experienced users can use it instead. Professional games use loading screens in this manner quite often, it would be very useful for us to be able to do the same if we want to. While C2's memory management as it is is fine for many games, it isn't optimal for all types of games, and this way we could choose how we want it to

The confusion could be solved by having a button that would toggle on/off advanced actions from the view. But I guess no point having that just for one action.