SpriteSheets are wasteful

If you hold shift and press crop in c2's image editor, it will crop all the frames and keep the location of the origin point. That will fix the problem with the blank space. It's not as efficient as if c2 attempted rotating images though, that would be a good improvement.

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.

I would agree with Kronar's idea about rotated sprites in export, I'm not sure Scirra team would change it.

Kronar It doesn't affect jitter on animation movement like original if we did a proper method, I had a solution, first off, import raw animations with empty spaces (eg. margins and padding) then shift + click on "crop" icon and then right click on animation list, "Preview" the result is same as original, not jitter.

Joannesalfa Is your method different than Arima? Lets walk through the steps.

Suppose you begin with an animation like the one I posted. All frames are identical in size and have the same origin. Lets say the origin is 80, 120. Its important to try a realistic example where the origin is not at the center.

1) Shift + click on the crop icon. This trims the empty space in each frame in an animation. Now all frames have different sizes and all of the origins also have different values.

2) Preview the animation. Observe the jitter between frames.

Did I miss something? It would be nice to have the cropping working as you suggested as that is a major savings.

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.

I haven't encountered the jitter you're talking about. I'm not sure what you're doing that makes it not work for you.

Here's an example, press shift crop and it will be aligned the same as if you didn't press it. If you have the object rendered so the center of the image is where you want the origin point to be, then you don't need to edit the origin point at all. Just import, shift click crop, done.

http://www.amirai.net/forums/cropexample.zip

Now all frames have different sizes and all of the origins also have different values.

This should not happen, you can place origin wherever you want and it will stay the same place after cropping.

Did not tested this in newest beta...or even last stable version - so either there's an issue on C2 side or your side.

very interesting thread... i learned a lot

thanks

Kronar

1. Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

No, it isn't. It can handle spritesheet-style animation just fine.

2. 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

No, it isn't, and it's incredibly inefficient to waste time rotating the images at runtime as that would just create MORE image data in memory, not less. We're not talking about 1990's-style hardware-supported sprite rotation, C2 is based on entirely different set of technologies. The amount of space saved is absolutely minimal both in terms of file size and memory footprint. I've NEVER been in a commercial production setting where this was ever considered a good idea, in games or elsewhere.

3. I took the time to thoroughly explain the problem so that the community and project would benefit. I want Construct 2 to continue to improve, I thinks its a great application. It already supports independent origins with each sprite frame so supporting a third a party application would be pretty easy to implement. This definitely takes priority over less useful new features like Spriter as using a spritesheet is a requirement not an option. Every single Construct 2 user would benefit greatly form this, even Spriter users would benefit.

Your information is entirely incorrect, and for someone who's attempting to make a point on optimization, you should probably find out what Spriter actually allows you to do and what a spritesheet actually is, especially in terms of how C2 handles them on export.

4. Let me reiterate by saying that If spritesheets were properly packed, the benefits would be HUGE. This isn't a small gain, or a good gain, this is a HUGE gain.

Really, there would be hardly gain at all, if any, if you didn't purposely leave a ton of white space around your example images. Even under normal circumstances, without that additional white space, the gains would be next to nothing.

5. It would not be uncommon to see a large reduction in file size, very large memory requirement reduction and FPS boost. All this without lifting a finger. All Construct 2 games would instantly gain that, no additional work, all done automatically for you.

Yes, it'd be pretty uncommon, because there's a point where optimization reaches a level of diminishing returns/pedantry that simply isn't useful on modern hardware, from mobile all the way to desktop. There isn't a single reason there would even be single-digit FPS gain. Your beliefs that it would matter seem to come from either a complete lack of how modern hardware functions across platforms or a background in an entirely different form of development than that which C2 subscribes to.

Kronar You DON'T need to change origin, the raw animation, for example, its original size like 150 x 150 including margin. Import all frames once time, then click shift + click on crop icon. It's flawless.

I would be very interested to see Ashley comment on this thread. The example given going from 8mb ram to 1mb is a very compelling reason to at least look this possibility. I have had projects where the artwork was too much for a number of devices and looking at the exported images there certainly appears to be scope for improvements to the memory usage.

Here is an example from an export two buttons only 128x64 are stored on a sheet 256x256. At this size it isn't a major but it is principle, I expected the packer to be more efficient.

Kronar

1. Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

No, it isn't. It can handle spritesheet-style animation just fine.

Spriter is a great tool, but there are some types of animations that spriter is not suitable for, like prerendered 3d. I think that's what Kronar was talking about.

2. 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

No, it isn't, and it's incredibly inefficient to waste time rotating the images at runtime as that would just create MORE image data in memory, not less. We're not talking about 1990's-style hardware-supported sprite rotation, C2 is based on entirely different set of technologies. The amount of space saved is absolutely minimal both in terms of file size and memory footprint. I've never been a commercial production setting where this was ever considered a good idea, in games or elsewhere.

Rotating an image at runtime does not use more image data in memory than if it was not rotated. Rotating an image at runtime does require more work for the gpu than not rotating it, but requires so little any affect on the framerate will only be noticeable on a weak mobile device.

When exporting, if rotating images to fit on a texture reduces two 512s to one 512, it certainly does seem worth it (perhaps rotation could be an option if people didn't want to use it to ensure maximum performance on old mobile devices).

digitalsoapbox I think he's not talking about runtime, it's about sprite sheet design.

Spriter is irrelevant here, it's not related to Construct 2. However Spriter can handle million of animations, but it's not related to sprite sheet.

Thanks for that example Arima, very helpful. I see how your animation gets cropped and plays back properly without jitter. I will figure out how to align my pre-rendered 3D frames/origin similar to your 2D artwork. Thanks again, this will be a nice savings.

Spriter is a great tool, but there are some types of animations that spriter is not suitable for, like prerendered 3d. I think that's what Kronar was talking about.

I never said it was the best way to do it, but it is capable of doing it, with the addition of the ability to define hitboxes and sound triggers in Spriter.

Rotating an image at runtime does not use more image data in memory than if it was not rotated. Rotating an image at runtime does require more work for the gpu than not rotating it, but requires so little any affect on the framerate will only be noticeable on a weak mobile device.

That depends on how it's rotated and how often. If it's rotated in-game by rotating the sprite, then it needs to do that, along with resizing the sprite if the images are different sizes, every frame. Saving memory and still ending up with a potential framerate drop is not exactly a positive tradeoff.

If it's rotated in memory, that makes rotation dependent upon the GPU, and since C2 strives to support non-WebGL accelerated devices as well, chances are it'd have to create a copy of the original sprite, rotate it, then remove the original sprite from memory - which would most likely involve rewriting how C2 handles images in memory, keeping in mind that when not using WebGL it loads all images from the project at once, and the memory spikes that would be caused by rotating images at runtime could push many mobile games over their limit. And that all assumes that HTML5/JS, outside of full hardware-accelerated WebGL, even has the capabilities to do it quickly. Which is questionable.

If rotating images to fit on a texture reduces two 512s to one 512, it certainly does seem worth it (perhaps rotation could be an option if people didn't want to use it to ensure maximum performance on old mobile devices).

That's making an assumption in terms of GPU power, and I'm still not buying that there would be any significant memory savings - while not impacting other areas - by doing so.

Spriter is irrelevant here, it's not related to Construct 2. However Spriter can handle million of animations, but it's not related to sprite sheet.

Except for the fact that the images attached to a Spriter animation are, themselves, added to a sprite sheet upon export?

I was also addressing a misunderstanding of Spriter's features made by the OP, so...yes, it's entirely relevant.