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