SpriteSheets are wasteful

Discussion and feedback on Construct 2

Post » Thu May 15, 2014 1:12 am

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 ran into the same jittering issues my self after trying to the use the "crop" feature in C2. I share a lot of your same concerns @Kronar but I think you'll need to crop and pack everything manually, as I have had to do.

One thing I have noticed over the past two years, is that generally this type of issue will not be addressed. The people in charge handle C2 in a different way. They prefer to add more features over quality features, which is their choice. But, for now, don't hold your breath.
B
56
S
15
G
13
Posts: 826
Reputation: 17,705

Post » Thu May 15, 2014 1:22 am

Doesn't the "jittery" thing from cropping only come about if you didn't set the origin points first? Shouldn't it go
1) Import all images (lets say they are all 128x128)
2) On any frame, position the Origin point.
3) Right-click the "Origin" point on the little floating window and click "Assign to whole animation"
4) Hold SHIFT and click the Crop icon.
5) ???
6) PROFIT

@Tekniko , I kinda disagree that they add "more features over quality features". I think it happened a lot in the early days, which is shown by the fact that the image editor is a bit "eh" (I'm aware that c2 shouldn't be an image editor, but there's a few issues with the GUI), but as time went on and newer features got added, more quality was put into them (SpriteFont is awesome, Multiplayer is awesome, ect). Things get addressed pretty well, it just requires good reason.
B
51
S
20
G
10
Posts: 571
Reputation: 9,819

Post » Thu May 15, 2014 1:44 am

@Tekniko Thanks for your comments. I agree with you and its ultimately what I am going to have to do. Its crazy that something so basic and standard is absent in Construct 2. I like the tool but there is a lot of room for improvement.

@Jase00 That works if you have setup your images correctly. I am trying to do that now with my pre-rendered 3D images now. Its not easy since I have additional processing to do in PS now. The point is that all this can be avoided if Construct would simply support packed spritesheets. Also cropping alone is a savings but nowhere near as much as a properly packed spritesheet.
B
5
S
1
Posts: 24
Reputation: 423

Post » Thu May 15, 2014 3:27 am

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

Post » Thu May 15, 2014 3:55 am

czar wrote:@Arima when you say cropping what do you refer to? Is that a step you can do in C2? I prepare my images in photoshop.


There's a button to crop the image in C2's image editor.

All I mean is, in photoshop, try resizing the image to 126x62 and import that into C2. Then try exporting. If it works, it's because of C2 adding a pixel width border to the image.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Thu May 15, 2014 10:40 am

Joannesalfa wrote:@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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Thu May 15, 2014 11:24 am

Kronar wrote: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.
Who dares wins
B
57
S
17
G
21
Posts: 1,878
Reputation: 19,592

Post » Thu May 15, 2014 11:54 am

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.

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?

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.

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.

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.

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).
Scirra Founder
B
402
S
238
G
89
Posts: 24,637
Reputation: 196,071

Post » Thu May 15, 2014 12:04 pm

@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)
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Thu May 15, 2014 12:11 pm

Ashley wrote: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.
You think you can do these things, but you can't, Nemo!
Just keep reading.
Just keep learning.
B
65
S
16
G
9
Posts: 1,429
Reputation: 12,728

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests