spritesheet optimize

Ashley

if a single object animation is spritesheeted on two sheets, does that mean, it needs to switch constantly between them? with other words

as long as it fits a 2048 texture, would it not be better for it to be on 1 sheet,

like instead of 2x512 = 1*1024 ?

or maybe even a 512 * 1024 ?

or anyone else has a explaination?

Texture atlases and sheets only help with batching, as less textures means more quads can be drawn using the same material without having to issue render commands for individual sprites.

As long as all the required textures for a given scene fit in memory, the actual organisation of the sprites has only a minor impact. It's always possible to fine-tune when hand-crafting everything manually, but in the context of a C2 game whether an animated sprite is using frames from different sprite sheets or not should not be detrimental to performance.

Though it would be interesting to know the logic that decides the size of the atlases I guess some platforms are still limited in terms of hardware when it comes to large textures

So why would using different objects have extra drawcalls, while one object with multiframes only one, i think i read its because of textureswitching?

would it be possible to fit a 512*1024 , isn't that also a power of two? this would save memory, i think i have an instance where this should perfectly fit,

also it sometimes a shame to loose great texturespace just because a graphic is a couple pixel to big, while in some cases, the size is not really as important. so a resized version should work ..

edit: it is said, 2048 is maximum for mobile, (for maximum compatibility) but thats fine..

i mean one object , using many instances is the most optimized, but you can set many different frames, is still one call

why would another object that also has been loaded in memory, be an extra call, while using the same object on different frames is not, if the texture sheet is of no importance?

than everything could in theory be called like its one object, just referencing the spritesheet and coordinates

You're absolutely right that additional sheets can and will generate more draw calls ; what I meant by "minimal impact" is that the cost of a few extra draw calls (i.e. a few factors e.g. 2x-10x, as long as there's no order of magnitude e.g. 100+x) is pretty negligible in terms of performance. Though we should think in terms of materials, as objects and/or textures usually don't relate directly to the number or complexity of materials

Basically there are games where each model can require dozens of drawcalls (typically, games with a lot of character customisation, like MMOs, lots of materials, armor pieces, etc. making batching difficult) ; for these, the frame time spent in the graphics drivers start to matter. Assuming a med-size 2D, not so much

I don't have the answer to explain why the atlases don't batch everything in one sheet in your case (and I'd love to know too !), but unless you clearly identified a perf killer or bottleneck through actual profiling, I wouldn't worry and would continue to progress on other fronts while waiting from an answer from Ashley or someone who knows the internal logic of the texture batcher

Refeuh thank you for your answers,

yes i know minimal impact, but still on that low level is pretty important its the best it can, specially because its about possible hundreds of objects,

im not on hold because of this, it just interests me

only thing i can think of is that the textures need square power of two, if thats not the case, there is much to be gained by optimising this, but i suspect there will be something i have not considered

just and idea.. i wonder if would be possible to set the resolution on the texture atlas, the objects would hold its normal dimension, but the textures coordinates would be scaled by that factor, in theory you could then have as small or as high of a texture resolution depending on a setting

The spritesheeting strategy is described in some detail in this blog post, although it's a little out of date now (e.g. the maximum spritesheet size is now 2048x2048 instead of 512x512).

The spritesheets have to be square power-of-two to avoid wasting memory on some devices (even if others can do non-power-of-two). Also note that bumping up a 1024x1024 texture to 2048x2048 uses four times as much memory, not twice, so it can be very wasteful to use spritesheets which are unnecessarily large. These days memory use is the main concern, since users tend to develop intensely memory-heavy games and sometimes find it crashes the device if it runs out of memory. So one of the strategies used by the spritesheet builder is if something fits on say 1024x1024, it will also try a 512x512 tile, or two 512x512 tiles, or three, as a way to save wasting memory with empty space on a larger sheet.

More technical concerns are: most third-party plugins aren't written for spritesheeting, and it's tricky to tile images unless they go in their own texture, so tiled background images don't get spritesheeted. Also perhaps surprisingly putting everything on to one giant spritesheet can actually significantly increase the download size of the game. Often individual objects can losslessly compress down to PNG-8 - sometimes around half the file size - because they use less than 256 different unique colors. However if you bundle everything on to one giant sheet, it becomes much more likely that there are more than 256 colors on the sheet and it gets bumped up to PNG-32, which produces larger files.

I don't think the performance is really an issue. In extreme cases with thousands of objects the draw calls can add up, but there are ways of dealing with that. In most real-world games I don't think switching texture poses a significant performance burden.

When I first wrote it I thought it was simple enough, just a matter of dumping lots of images on to one sheet. It turns out there are technical factors and difficult tradeoffs like download size vs. memory use. I don't believe there is one strategy which is universally better.

Ashley

i'm not good in english i try to translate what you write and just tel me if i'm wrong or not

1- for example i have a sprite with width 80 and height 100 (with no transparanecy spaces)

then to avoid waste memory i have to make it as 100X100 with transparency spaces ?

what about the story about the 1 or 2 pixel around the sprite ?

2-is that same for tiled backgroud ? if the recommanded power of 2 is for example 128 X 128

then we have to put a png with 127x127 or 126 x 126 ?

i'm a little confused

matrixreal - don't worry about this when designing your games. It all happens automatically and is taken care for you.

Ashley thank you for explaining this more,

the big problem i see with this solution is that an animation can be just one frame too big and take up an entire sheet, but is for the most part empty, i think there is still room for improvement by using this space, but perhaps thats the entire point why custom atlasses with lots of choice for arrangement is the better solution in the end, > not saying that current solution is bad, its pretty easy

this touches a bit on the fact that there are two groups that want to use c2

devs with years of experience want the "expert functionality" and really push things however they can,

for me using a certain method that i know there are better solutions, is pretty frustrating for me,

thats also what pushes technology forward i think...

and also devs who just got started with c2 and are happy with "easy default" solution, wich is great,

until they want more from the engine and there app/games

"animation can be just one frame too big and take up an entire sheet,"

This should not happen. If you have a sprite with 5 animations. Each frame is 126x126 px. Then it will make two images after export - 1 sprite sheet 256x256 with 4 frames and 1 image 126x126 with last 5th frame.

shinkan , i have many occations where i export and find sheets with lots of empty space (more then halve of the texturespace), granted, if you then start figuring out how much each should take to optimal fit , also not everything is is square sized... i check if i find some examples

shinkan

shinkan

That depends entirely on texture size you have for each frame.

Each frame on spritesheet have 1px border around to prevent pixel bleeding.

Each frame of animation also should have 1px empty border around for antialiasing.

So when you have 5 frames animation and each frame is 64x64 then after exporting you will get a 256x256 file with a lot of empty space.

But if you make frames 62x62 then after export you will get 2 files: one 128x128 with 4 frames and one 62x62 with 5th frame.

And if you want your sprite to have nice and smooth edges, you need to add 1px empty border around your sprite. Which will make your actual texture 60x60 (while frame is 62x62)

If you learn how to use it properly then C2 actually is quite good with making the sprite sheets out of the textures on export. Just need to remember about some things while making your textures.

Like this green things on your first image. If they were 254x126 and be only 10 of them then you could fit 8 frames on one 512x512 and remaining 2 frames on 256x256 - no space wasted.

That's how C2 works. And all you can do is to accept it

64size.capx

62size.capx