Is there a use of a layout to layout preloader?

0 favourites
  • 4 posts
  • I noticed that many still suggests layout to layout preloader. They use it to preload images of the objects that they are going to create/spawn during gameplay but not initially present on layout startup.

    For example; I were to make an rpg game. All RPG games have so many maps so I need to make a lot of layouts for maps but the player objects are used in each layout but it will be very unorganized if I put the players and bullets on each layout (map). So I will make a preloader layout to store all the players, clothes, enemies, bullets that are going to be spawned during gameplay on the maps (game layouts).

    If you think about this, it will be a very good time saver until you read this on the manual, saying that this is useless:

    Construct 2 only loads the images for the current layout. This avoids loading the entire project in memory which would be slow and consume a great deal of memory. When starting a layout, all images for the objects placed in the Layout View are pre-loaded. This includes all frames in all animations of any Sprite objects. (In other words, Sprites are either fully loaded in to memory, or not at all - they are never part-loaded.) When the layout ends, all images that are loaded but not used on the next layout are released from memory.

    If an object is not placed in the layout view, but events create it at runtime, its images are not pre-loaded. The Construct 2 engine is forced to load the object images at the moment of creation, which can cause a momentary pause in the gameplay, or in extreme cases a constant stuttering (also known as "jank"). In order to avoid this, simply place any objects that will be used by the layout in the layout view. If they are not immediately needed then they can be destroyed in a Start of layout event. They will then not exist when the layout starts, but Construct 2 will still have pre-loaded their images, ensuring that they can later be created at runtime without any jank.

    Emphasis:

    When the layout ends, all images that are loaded but not used on the next layout are released from memory.

    If an object is not placed in the layout view, but events create it at runtime, its images are not pre-loaded

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    In a different angle of view:

    If people suggest adding both images on the game layout & preloader layout so that there will be respect to what the manual said :

    all images that are loaded but not used on the next layout are released from memory .

    So there will be no images that will be flushed from the memory since the images are present on the "previous" & "next" layout.

    The purpose of this is to preload the images of the objects that are going to be used on the next layout. So it will be preloaded without getting flushed from the memory.

    Well I believed this until I tested it. It seems that a huge FPS spike will happen on start of layout that can cause glitches to anything that is created on start of layout. This happened to a test platformer I made with solid ground using a preloader if layout image memory is above (30+).

    *BTW. Correct me if I made a mistake*

    So experts please explain, are we doing it wrong. Did I miss anything? Should we leave this idea or should we continue to use this?

    Thanks .

  • As far as I'm aware, the scml object requires the action of one event to associate all of the spriter objects together, and that's only once per project (the trigger doesn't run every layout). But as for other game assets, I don't see the need for loader-layouts as you describe. Better to have a false loader-layout where everything you need is created and stored in memory before the layout is enabled to start in full game mode.

    Edit: Webfonts also require a once-only loading per game.

    Edit2: I'm still not an expert...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • - Without you knowing, you helped me solve my scml object problem in initializing .

  • I'm always happy to inadvertently help!

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