SpriteSheets are wasteful

Discussion and feedback on Construct 2

Post » Wed May 14, 2014 10:34 pm

@czar It's your design. Every sprite sheet must be power of two.

You should adapt a form as background image in one frame, then use sprite font like YES, NO you could save a lot of memory.
B
99
S
35
G
29
Posts: 3,139
Reputation: 28,421

Post » Wed May 14, 2014 10:39 pm

Joannesalfa wrote:@czar It's your design. Every sprite sheet must be power of two.

You should adapt a form as background image in one frame, then use sprite font like YES, NO you could save a lot of memory.


Or, even better, use a 9-Patch for the button itself with a sprite font on top, which eliminates the need to create differently-sized buttons entirely.
B
84
S
46
G
25
Posts: 528
Reputation: 21,566

Post » Wed May 14, 2014 10:49 pm

I kinda agree with the OP, but nothing is going to change unless you can prove to Ashley what your talking about.

I've voiced that C2 should use an Image library. That way any object can reference any image. Including being able to create dynamic animation sets. Also I voiced that an Image Library can be easily atlased. However the idea was shot down.

Ashley claims that atlasing does not have worth while improvement gains. Yet atlas is one of Unity pro's big features for the cost. I've seen Unity atlast and the images are rotated every which way to fit best. Also WebGL rendering has no overhead for rendering rotated images. It's just UV coordinates.

If you want to prove your performance point which I do agree with. I suggest creating your own intensive JS webgl image rendering app( just a test). Run it with a better packed sprite sheet, then run it with a C2 exporter spritesheet. And then display the cpu/gpu/mem usage for both. If you can and I hope you do prove the benefits. Then we will see the change. But this is one of those subjects that Ashley is firm on.

Also to let you know. Each Sprite Object runs it's own sprite sheet. :(
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Wed May 14, 2014 10:54 pm

@digitalsoapbox I think you don't understand how Spriter works.

Spriter is almost-frameless animation editor can save JSON or XML data in export to manipulate position, scale, frame, etc. when it's exported, sprite sheet is small and simple because it has 5 parts of graphic thanks to C2 editor, BUT depending on the video game design.

If we use rendered frames by 3D like rotating cube in isometric in Spriter, it doesn't make sense.

There an interesing point about different angles in sprite sheet could reduce size thanks to Tangram logic, we will see what happens.
B
99
S
35
G
29
Posts: 3,139
Reputation: 28,421

Post » Wed May 14, 2014 10:57 pm

All right say your sprites are all 79x93, and you have 12 of them.
Width wise they will fit into 512 easily, and give you some empty padding.
Height wise they wont fit into 512, and that means you have to go to the nearest power of 2, which is 1024.

Now this brings up the question of what could be designed better, the way the texture is set up, or the way the individual textures are drawn.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Wed May 14, 2014 11:09 pm

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


Great, glad it helped!

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


Cropping should fix that problem.

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


I'm guessing that's because of C2 adding a 1 pixel border when cropping to get 'free' edge antialiasing. If you resize the image to 126x62, does it work?

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


Ah, I misunderstood your point.

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


That's actually not how it works. Think of it like this: you have a piece of real world paper, and a stamp. It doesn't matter what angle the stamp is at when it touches the paper - the gpu calculates it in real time when drawing the pixels, and needs to make no modification to the stamp itself to do so, and it incurs almost no performance hit in the process, because gpu makers have optimized the operation like crazy.

If it worked the way you suggested, practically no 3d game would be possible because every single texture on every polygon of every model is being distorted in an uncountable number of permutations based on perspective, angle and animation. It would use a ridiculous amount of memory to do so and would be completely pointless as very little of the saved work could be used ever again. Even if instead of saving an extra copy of the texture it just overwrote the original, the quality of the texture would degrade as it got blurrier and blurrier from being filtered over and over again.

Also, when not using webgl, canvas2d is used which is still hardware accelerated, just not as efficiently. Even software rendering such as chrome uses still doesn't need to use more image data in memory to rotate a sprite because it emulates the real time process hardware acceleration uses.

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


That's why I said it could be an option.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Wed May 14, 2014 11:37 pm

Arima wrote:That's actually not how it works. Think of it like this: you have a piece of real world paper, and a stamp. It doesn't matter what angle the stamp is at when it touches the paper - the gpu calculates it in real time when drawing the pixels, and needs to make no modification to the stamp itself to do so, and it incurs almost no performance hit in the process, because gpu makers have optimized the operation like crazy.


Actually, it depends less on the GPU makers/drivers (outside of stability) than the technology being used - in this case, HTML5/JS through C2. C2 isn't a 3D engine. Yeah, some things are similar in terms of what goes on GPU-wise, but different things work different ways. Either way, wasting cycles rotating an object to save a few kb in a bitmap isn't worth it in this day and age, where even our slowest smartphones are faster and have more memory than the hardware available at the time when rotating sprites to save a few bytes was even a relevant discussion.

Arima wrote:If it worked the way you suggested, practically no 3d game would be possible because every single texture on every polygon of every model is being distorted in an uncountable number of permutations based on perspective, angle and animation. It would use a ridiculous amount of memory to do so and would be completely pointless as very little of the saved work could be used ever again. Even if instead of saving an extra copy of the texture it just overwrote the original, the quality of the texture would degrade as it got blurrier and blurrier from being filtered over and over again.


3D uses UV mapping on a per-vertex or per-triangle basis in general, for starters, so it's not even close to comparable. In fact, it's a bit like comparing apples not to oranges, but to, say...a polar bear. I'd be happy to PM you a few links on the subject if you're interested in learning how different it is. I think a couple books I wrote on the subject that were published by actual book publishers might still be in print. They're kind of old, but the theory is the same.

Also, doesn't C2 use quads for drawing in canvas2D? In which case, it's WAAAY different than 3D.
*EDIT: It does: https://www.scirra.com/blog/58/html5-2d ... e-analysis

Maybe you were thinking of projection mapping? That's sorta-kinda stamp-like.

Arima wrote:Also, when not using webgl, canvas2d is used which is still hardware accelerated, just not as efficiently. Even software rendering such as chrome uses still doesn't need to use more image data in memory to rotate a sprite because it emulates the real time process hardware acceleration uses.


As I think I said somewhere in a previous post, that depends on what kind of rotation we're talking about. And considering the inefficiencies inherent with the 2D canvas, the tradeoff isn't worth it because, again, the savings are minimal memory-wise (and really, who cares about 8MB when even a phone capable of running C2-based stuff from 2 years ago has significantly more memory) and could potentially have a negative impact on the actual, real-world performance of games we make by worrying about other things like sprite rotation in a sprite sheet (aside from the whole power of 2 thing someone else mentioned). If you're THAT WORRIED about performance, maybe look into learning to use the tools that are available, right this second, in a more efficient way. A couple megs on a sprite sheet isn't going to hurt anything. If it is, you're doing something wrong.

I would wager a majority of performance issues are the result of user error. Every time I've wanted to blame C2 for a framerate drop, it's because I've actually been the one doing things wrong. All it takes is a trip to the manual, or these forums, and a few keywords. People are here to help find solutions, and are almost always pretty friendly about it, but it'd be great if we could steer clear of blaming C2 for not having a feature that isn't completely necessary and may in fact be hurtful to its performance.
B
84
S
46
G
25
Posts: 528
Reputation: 21,566

Post » Thu May 15, 2014 12:14 am

Heck, lets just go encapsulated. Lets stick all the assets into base64 strings, and stick it all into one js file.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Thu May 15, 2014 12:59 am

digitalsoapbox wrote:Also, doesn't C2 use quads for drawing in canvas2D? In which case, it's WAAAY different than 3D.


That's incorrect. Quads use vertices and uv coordinates same as polygons. They're essentially the same thing. A quad is basically two triangular polygons. http://archive.gamedev.net/archive/refe ... index.html

I've heard that OpenGL even sometimes automatically breaks quads into two triangular polygons. Everything I have ever read or heard on the subject matter, including from professionals in the game industry, has told me that hardware accelerated 2D is rendered in the same way 3D is in almost every circumstance. They really are essentially the same thing.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Thu May 15, 2014 1:04 am

@Joannesalfa I am not sure I understand, 128x128 is to the power of two, so why would it go to 256x256? As for making buttons using front sprite, yes I understand that I can do that but I was demonstrating a point here regarding the inefficient packer.

@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.
B
37
S
9
G
5
Posts: 437
Reputation: 6,094

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Colludium and 9 guests