SpriteSheets are wasteful

czar I can see you use 2 frames as 128x64, it would go to 256x256

Don't bother to make sprites as power of two just use smaller images like 100 x 50 then upscale in editor, let C2 export will work for you.

That is because C2 will add one pixel between each frame, I think a section of the manual describes this, but I do not remember which one ATM.

The images were purposely not cropped because aligning different sized images to have the exact same origin would be incredibly difficult and nearly impossible to maintain (in case you change any image). Even cropped versions would still be incredibly wasteful.

Took me a bit to get the hang of too.

Arimas methods are spot on.

My method:

I export sprite sheets from utility, in a row per angle. (8 isometric angles)

Import sprite sheet(s).

Resize entire animation (per angle/row) so resulting image in the center is the size I want, then crop entire animation by holding shift while cropping.

I refrain from changing origin point 0, so the frames always align neatly the same.

The only downside I really noticed, is having lots of animations (with all angles) has the potential to enormously bloat the program.

Not so much due to inefficient sheet creation, but the sheer amount of images involved.

Spritesheets are not as inefficient as you're making them out to be, and I disagree there are "huge" improvements that could be made. It's probably not perfect, but like with all software engineering we are making a tradeoff of getting most of the optimisation benefit while keeping 100% compatibility. This is a subtlety most users aren't aware of. It's easy to sit back and say "omfg construct 2 sucks why don't they just do this", but we have in fact already carefully engineered it and there are usually good reasons for things being the way they are. If you look at the blog post on Spritesheets when they were originally introduced, there were concerns we addressed such as keeping the progress bar feedback working, automatically color counting to PNG-8 and the impact on download size if a spritesheet pushed it over 256 colors, and backwards compatibility with third party plugins (so we didn't break a wide range of plugins with one fell swoop). The recent 'downscaling' quality setting also impacts this, since if objects are not power-of-two aligned in their spritesheet, bleeding between unrelated images can occur at low mipmap levels, introducing glitches in to the game. This is the type of difficult technical issue it's probably easy to gloss over if you're not actually working on the engine.

[quote:3nm0xv63]Other engines and tools pack spritesheets by trimming empty space around images

Construct 2 lets you do this easily with shift+crop in the animation editor. Jitter should not occur assuming the origins are all in sensible places (and you can also place them all at once with shift+click when placing the origin). So if you have fixed size animation frames, shift+click to set the origin, then shift+click crop, and you should instantly have a whole cropped animation with no jitter. If you get jitter, please file a bug report, nobody else has reported any issues with the current system.

It doesn't crop automatically since it could affect the way the game works, particularly with WebGL shaders, where it may be intended to have a region of transparency preserved around an image. Also, surely maintaining the correct offsets if the image size is changed would add performance overhead? Given Construct 2 can arbitrarily scale and rotate objects, if the image size is not the same and it stores an offset, it would have to do trigonometry calculations every draw to work out the correct draw position, right?

[quote:3nm0xv63]Another inefficient area is with duplicated frames in animations.

Construct 2 already deduplicates identical frames, but they must be exactly pixel-perfect identical. See Construct 2's export-time optimisations. If that does not appear to be working for you, file a bug report, but AFAIK it's working OK.

[quote:3nm0xv63]90 degree rotations are trivial and at the GPU(webgl) and software levels(canvas2d) have no performance penalty.

It's easy in WebGL mode, but I don't think it's convenient to do in canvas2d: the drawImage overload that specifies a source rectangle does not support rotating the source rectangle. It could cut out the source rectange and rotate it to a separate image, but that could increase the startup time as now it needs to do extra image processing, and could negate the memory savings since the cut-out image may sit on its own power-of-two texture in GPU memory.

[quote:3nm0xv63]This isn't a small gain, or a good gain, this is a HUGE gain.

Can you back this up with measurements? I think it may be improvable by a few percent, but if you can show why the gains are huge, and there are no difficult technical issues to work around or hidden downsides like with cutting out rotated images in canvas2d mode, then I may be more persuaded.

[quote:3nm0xv63]Ashley claims that atlasing does not have worth while improvement gains

Citation needed! I wrote a whole blog post on it, covering a list of benefits at the end! And why would I have gone to all the trouble to implement it if there wasn't anything to gain?

Please don't now all go away and say that the creators of C2 don't care, we don't listen to our users, or whatever. Real engineering is not about clicking your fingers and magical rainbow unicorns appear everywhere. It is mostly tradeoffs, sometimes very subtle, that must be carefully balanced. If anyone could show an easy zero-downsides way to improve spritesheets I'm all ears, but I don't see any in this thread, nor any measurements to indicate precisely how valuable they are with typical usage of Construct 2 (such as appropriately cropping all frames).

Ashley : It occurs to me that the spritesheet C2 exports when there is mostly than 1 frame are always a size of A x A (A being a power of two, the same number for both sides), I do not clearly understand why a rectangular sheet wouldn't be possible?

(And also the power of 2 sides only, for that matter, is not that clear to me, I though some weak gpu would fill themselves the missing spaces, not that C2 should fill them, could have misunderstood that)

Real engineering is not about clicking your fingers and magical rainbow unicorns appear everywhere. It is mostly tradeoffs, sometimes very subtle, that must be carefully balanced.

This sums it up nicely, and why I have learnt to trust ashley's choices in making this great software.

I do not clearly understand why a rectangular sheet wouldn't be possible?

Low-end GPUs only support square power-of-two texture sizes. Also, I don't think even having non-power-of-two texture size support actually guarantees that in memory they are a non-power-of-two size - it could still put it on a power-of-two size and just emulate non-power-of-two support (e.g. by reporting a different texture size to what's really allocated). Square power-of-two guarantees that the GPU texture will also be exactly the size of the spritesheet.

I am not exactly sure I get it yet, if the image was not power-of-two sized, it wouldn't make a difference for low-end GPU then (since they will consider it like a power of two size still), but will be in theory a smaller filesize at the end, and also:

Square power-of-two guarantees that the GPU texture will also be exactly the size of the spritesheet.

but in that case, the the added texture ins't used either, unless it means the GPU would deteriorate the texture in case of non-power of two, but since 1 frame only objects aren't spritesheeted nor resized, it seeems unlikely to me

Ashley

EDIT: I misread, low end GPU doesn't support at all then, but it is still weird for the non-power of two sized exported for one frame, that they works

The only way I can think Construct 2 could be improved in terms of performance is to have spritesheets shared between animations (I may be wrong, but I remember seeing the folders separated by animations).

But the spritesheet system is already robust and awesome enough for our needs!

Aphrodite Basically if the texture/sprite image is not a power of two, then the computer will add blank space to it to make it a power of two. This means it will increase the size. So for example if your image is 240x512 it will be converted to 512x512. If it is 500x500 it would still be converted to the next compatible power of 2 size which would be 512x512. It does this because it can't remove space to make it fit since that would cut the image.

but will be in theory a smaller filesize at the end

PNG/JPEG compression will compress away empty space to effectively nothing, so in practice extra space in the image does not affect file size, only memory use.

[quote:3gnhec7u]have spritesheets shared between animations

They already are - a spritesheet can have images from all the animations of one object type on it. Two different object types won't share a single spritesheet, but then that probably helps keep the colour counts down (since animation frames of the same object type are likely to use a similar palette), making it more likely the whole spritesheet can go to PNG-8 and significantly save on the file size. Also as mentioned in the blog post, if everything ended up on one giant spritesheet, there would be no progress feedback while loading, so it's useful to break things up across a few spritesheets for that too.

Arima Thanks for your suggestion. I just tried it and unfortunately did not work. The origin points will remain in the same place for each frame but because of the frame size differences the animation playback will 'jitter'. For cropping to work, the engine needs to take into account how much got cropped off in each frame and offset each origin appropriately.

Kronar

I have a thread about this issue. I have a solution that works great also. Cropping still works beautifully. I saved tons on memory usage by implementing the "fix"

No jittering. Smaller sprites due to proper cropping.

Lol, just saw this on twitter:

Product of Death Cycle

[attachment=0:48dwg73z][/attachment:48dwg73z]