R129 Spritesheeting algorithm

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

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.

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

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.