SpriteSheets are wasteful

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.

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.

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.

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.

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.

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!

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.

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?

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.

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.

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.

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.

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.

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.

Heck, lets just go encapsulated. Lets stick all the assets into base64 strings, and stick it all into one js file.

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.

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.

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.

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.

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.

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.

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.