SpriteSheets are wasteful

Discussion and feedback on Construct 2

Post » Wed May 14, 2014 8:01 pm

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.

Cropping is always handled by a utility or the engine itself. For instance in Unity 3D, all cropping, packing and rotating is done automatically for your 2D games. Even third party libraries such as TK2D do all of this. With other engines like Corona, Moai, Marmalade or cocos2d etc..., it is done externally with an application like the one I mentioned. You don't ever want to do this by hand, not only would it take many hours for a single spritesheet but it would be prone to being inaccurate.

Regarding your comment on duplicates. Please do tell the secret on how to add frames and avoid duplicates in spritesheets. Construct 2 should easily be able to tell duplicate images and not repeat them wastefully in spritesheets. This is a bug.

90 degree rotations are trivial and at the GPU(webgl) and software levels(canvas2d) have no performance penalty.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 8:21 pm

Even if it was pre-cropped to the nearest pixel it might still have all the white space if those objects can't be placed to the nearest power of 2.
That would probably be solved, at least in this case by rotations.

As to the duplicates, I always assumed it was based on the object, if not to all the objects animations, as it should assumed there would be no duplicate textures on other objects, relying a bit too much on some planning on the users part perhaps.

Anyway we have to belay casting blame as there's only one person doing the development, and his todo list, even though it is legendary, is not public, and while those changes aren't exactly trivial, aren't basically basic.
Image ImageImage
B
169
S
50
G
174
Posts: 8,330
Reputation: 110,804

Post » Wed May 14, 2014 8:29 pm

@Kronar
I agree that this should be implemented, but for the most games made with C2 it wouldn't increase the performance too much.
One alternative solution to your problem is Spriter.
B
49
S
15
G
6
Posts: 534
Reputation: 7,195

Post » Wed May 14, 2014 8:47 pm

newt wrote:Sure is a lot of white space in the first image.
Those were not cropped before import?
As to the duplicates, I think that depends on how the texture is added.
Also, not sure if he can even do rotations. Surely it can for webgl, no idea for canvas2d.


Yes, there are a lot of white space but judging to different result from Texture packer, the angles are different.
B
99
S
35
G
29
Posts: 3,139
Reputation: 28,421

Post » Wed May 14, 2014 9:03 pm

@newt Where was blame cast?

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

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

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.

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. 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.
Last edited by Kronar on Wed May 14, 2014 9:09 pm, edited 1 time in total.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 9:08 pm

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.
Moderator
B
95
S
34
G
33
Posts: 3,006
Reputation: 27,874

Post » Wed May 14, 2014 9:17 pm

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

Post » Wed May 14, 2014 9:22 pm

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

Post » Wed May 14, 2014 9:38 pm

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

Post » Wed May 14, 2014 9:46 pm

Kronar wrote:@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
Moderator
B
95
S
34
G
33
Posts: 3,006
Reputation: 27,874

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: mihirolover, Tjums and 13 guests