SpriteSheets are wasteful

Discussion and feedback on Construct 2

Post » Wed May 14, 2014 9:49 pm

Kronar wrote: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.
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,598
Reputation: 34,823

Post » Wed May 14, 2014 10:03 pm

very interesting thread... i learned a lot :)
thanks
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

Post » Wed May 14, 2014 10:10 pm

@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.
Last edited by digitalsoapbox on Wed May 14, 2014 10:23 pm, edited 1 time in total.
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

Post » Wed May 14, 2014 10:19 pm

@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.
B
97
S
35
G
29
Posts: 3,139
Reputation: 28,371

Post » Wed May 14, 2014 10:22 pm

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.

Image
Last edited by czar on Wed May 14, 2014 10:27 pm, edited 1 time in total.
B
37
S
9
G
5
Posts: 437
Reputation: 6,094

Post » Wed May 14, 2014 10:24 pm

digitalsoapbox wrote:@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.

digitalsoapbox wrote: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).
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,749

Post » Wed May 14, 2014 10:24 pm

@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.
B
97
S
35
G
29
Posts: 3,139
Reputation: 28,371

Post » Wed May 14, 2014 10:29 pm

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.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 10:30 pm

Arima wrote: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.

Arima wrote: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.

Arima wrote: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.
Last edited by digitalsoapbox on Wed May 14, 2014 10:37 pm, edited 4 times in total.
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

Post » Wed May 14, 2014 10:31 pm

Joannesalfa wrote: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.
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: jobel, Rastacity, Studio Mercato and 3 guests