R129 Spritesheeting algorithm

  • I don't know exactly what they changed in this version, but it still works very badly.

    This is a capture of my game in C2.

    And this on C3.

  • Well that's the debugger.

    It's not known for being 100% accurate.

  • Oh, i thought last time you use c2runtime vs c3runtime. But you compare here C2 vs c2runtime in Construct 3

    New "Adjusted spritesheeting algorithm to save memory" could be only be for c3runtime.

    Anyhow. What a mystery this is :D

  • SnipG

    But you compare here C2 vs c2runtime in Construct 3

    The same thing happens in C3 runtime

  • You should not care about that number. You can resize that debug window and see it changes. Put debug stats on another tab and it will increase.

  • The change in r129 was relatively minor; we have some larger changes on the way for the next beta cycle.

    Spritesheets help ensure loading and rendering is efficient, but at the cost of potentially using more memory. C2 does not combine different objects on to spritesheets, so has lower memory usage but higher loading and rendering overhead. C3 does combine different objects on to spritesheets, so can have higher memory usage in order to attain lower loading and rendering overhead. It's a classic engineering tradeoff between two different priorities; however I think projects like this demonstrate that we need to improve the balance between the two.

  • "It's a classic engineering tradeoff between two different priorities; however I think projects like this demonstrate that we need to improve the balance between the two."

    When C3 matures enough. Could it be possible or if you consider it. Ability to give us different releases when there has been huge changes to C3.

    For example from perspective of this spritesheeting: Stable 150 - has current spritesheeting, release 150.1 has new one and so on. So users can benefit from different cases and are not stuck with just one.

  • Maintaining multiple different versions of the same feature is far more complicated and time-consuming than just having one, and time is by far our most limited resource. We really want to just have one algorithm, and tune it to work as well as possible.

  • Ashley - I just want to note that tunepunk and many users worked a lot of effort and time to have made the few very carefully thought out benchmark tests to point out that increasing the sprite-sheet count can have some non-worth it performance overhead, as you have also stated that it does.

    Reference :: construct.net/en/forum/construct-2/general-discussion-17/understanding-draw-calls-124967

    You also, spent time to design the sprite-sheeting algorithm yourself to pack as much assets into less sprite-sheet count as possible. To avoid the texture-swapping overhead.

    Please, just because one developer made some seemingly a project design error, doesn't mean you need to re-design the sprite-sheeting to increase the sprite-sheet count and reduce the performance again.

    One of the greatest reason Construct 3 is preferred is because of the well-packed images to target low sprite-sheet count, unlike Construct 2.

    We already noticed some very slight texture-swapping overhead, just from r129. That was from the 1% increase in sprite-sheet count from packing.

    Please, reducing the sprite-sheet packing will just hurt most of the optimized projects. Don't do this approach.

    Thank you for the time.

  • A possible solution would be an option to include, or not, the sprite in algorism.

    This would be great for sprites that appear very rarely and it would be great to include the sprites that appear a lot.

  • chadorireborn

    Please, just because one developer made some seemingly a project design error

    I do not think it's a design error, it's simply that being a large project loads many sprites in memory that you do not really need.

  • chadorireborn - the thread you linked to, apart from having quite a lot of confusion over how WebGL rendering actually works, is a good demonstration of the tradeoff. Conceptually we can imagine either extreme:

    Maximum spritesheeting - there is a single gigantic spritesheet that contains all the images in the entire game.

    Pro: the entire game can be rendered without ever switching texture. In ideal circumstances, this means a single draw call can draw everything! (Although things like opacity, blend mode, effects etc. will "break the batch" and add more draw calls)

    Con: the game always uses the maximum amount of memory. There is no possibility for memory management - either everything is loaded, or nothing is. For large games this means they may not be able to run at all if there is not enough memory.

    Or: maximum memory efficiency - every single image is a separate texture.

    Pro: minimal memory use, since memory management is effective at ensuring textures which are not needed are not loaded.

    Con: maximum draw call overhead - every time a different image is drawn, it must switch texture.

    You can't have it both ways - this is a tradeoff between each extreme. I think the maximum spritesheeting case is worse than the maximum memory efficiency case, since the game can fail to run at all if it doesn't fit in memory. On the other hand the maximum memory efficiency case may be slower, but at least it can run.

    Neither C2 or C3 actually does either of those extremes, but C2 is closer towards the maximum memory efficiency end, and C3 is closer towards the maximum spritesheeting end.

    @Taximan sent me their project by email which I am using to guide changes to the spritesheeting algorithm. In the case of their project, there was a signficiant increase in memory usage between C2 and C3, and it looks big enough that it may prevent some devices from being able to run the game at all. So I think it's good evidence we need to move back further the other way. In theory this could increase the draw call overhead, but as ever if people send me actual projects I can use them for testing and optimisation as I am doing with Taximan's project; otherwise I can only speculate. We do have some more changes in the pipeline though that should help both memory usage and draw calls, as well as giving more control over the spritesheeting process.

  • Ashley, would it make sense to offer an import of sprites, and spritesheets, via TexturePacker? As a way to let us optimize for certain platforms. But that’s a very different workflow from what Construct has now and might not fit the spirit of the product.

    For a more Construct-like idea, since you’re adjusting the packing algorithms, how about adding a control to project settings, to let Construct users bias the packing towards more or less memory use. Maybe set a max spritesheet size?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think the best option would be to be able to choose which sprites go into algorism, an option within the properties of the sprite would solve all the "problem".

    A sprite that is used many times would enter inside, another that is only used at certain times would be out.

    The user could manage the memory of his game, or mark all the sprites and let Construct algorithm work.

    It's just an idea.

  • Taximan

    I think the best option would be to be able to choose which sprites go into algorism, an option within the properties of the sprite would solve all the "problem".

    No offence, but this is impractical and slightly horrible. Too much work than necessary, that would remove the automated approach of Construct 3 and it is prone to error and one wrong move and your game crashes. I don't want to seem rude but I have to point out that we, including you, wouldn't want this. Always go for efficiency and simplicity.

    nacra

    For a more Construct-like idea, since you’re adjusting the packing algorithms, how about adding a control to project settings, to let Construct users bias the packing towards more or less memory use. Maybe set a max spritesheet size?

    This is looks like a practical solution. Wonderful idea.

    If we can't yet choose to manage each asset from a Construct 3 Sprite-sheet Editor. We can have something like this.

    Spriter Pro : Sprite-Sheet Packer

    This is not an exact design preview but it does give an idea.

    1. Set the Sprite-Sheet maximum size.
    2. Apply Padding, Spritesheet Count (Example : Single or Multiple) and Packing Rules. (Regarding Construct's case, a percentage would be suitable, from (1% to 100%). This can also be the performance from "Performance" to "Memory Efficiency".
    3. Shows the packing efficiency, performance and other information.

    Ashley, this might be a viable design to solve the issue about the trade-off as we can manage it but still under the automated approach under your packing algorithm. What can you say about it, is it a viable solution?

    Thanks for the time.

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