Turn off automatic sprite sheeting of assets in C3

Is there an option available for turning off the generating of a sprite sheet for the exported C3 HTML5 project (or a certain way to set up the project assets, so that they are not combined to the same sheet)?

No, because this will de-optimise your project. Why would you want that?

No, because this will de-optimise your project. Why would you want that?

We're working with a client, who wishes to have all art assets as a BLOB (Binary large object). Having all the sprites as separate images would make it easier to accomplish this, since the data.js file will then have image information correctly representing individual files rather than their positions on a spritesheet.

Currently I am able to accomplish this, but it requires extracting the images separately from the project file and also modifying the data.js (so it is a very hacky way).

Ashley I completely agree with you though that this cripples the project performance, but at least the client gets the desired result.

Additional question, do we get more control later on over what assets are included on each spritesheet?

For example, to optimize the memory overhead by ensuring that assets that rarely appear together will not get placed to the same spritesheet?

Thanks for the great work with the engine!

We're working with a client, who wishes to have all art assets as a BLOB (Binary large object).

You could provide the art assets to them separately. Why would they insist the exported version be like that? I'm afraid we need a good answer to that to justify spending development time on it when we have dozens of other things to be working on.

> We're working with a client, who wishes to have all art assets as a BLOB (Binary large object).

>

You could provide the art assets to them separately. Why would they insist the exported version be like that? I'm afraid we need a good answer to that to justify spending development time on it when we have dozens of other things to be working on.

They want to have the art assets hidden and reduce the amount of HTTP requests (the individual sprites I can easily encode as data URIs, but currently having to reverse the spritesheeting makes it a bit more cumbersome).

I think it's fine that the Scirra team focuses on other more important issues at hand. I only wondered, if this feature would have been easy to accomplish. Personally, I consider more important having the possibility of controlling which assets go to which spritesheets, for example, to ensure that the art assets can be handled in an optimized way (and unnecessary sprites are rarely loaded). Let's take the scenario of having a menu and a game layout. It would be better to have the game assets in a separate 1024x1024 spritesheet and menu assets in 512x512 spritesheet than combining them together to a huge 2048x2048 spritesheet to have a lower memory overhead. When going to menu, one could have the game assets unloaded, and while in game, the menu assets unloaded. Any plans on implementing this kind of feature? (e.g.a spritesheet group number as a variable for the sprite object, The logic could be with default value being 0 and then the spritesheet process works as it does currently, but anything else would be spritesheeted accordingly to the group number)?

They want to have the art assets hidden and reduce the amount of HTTP requests (the individual sprites I can easily encode as data URIs, but currently having to reverse the spritesheeting makes it a bit more cumbersome).

This makes no sense. Spritesheeting does reduce the number of HTTP requests. Besides, HTTP2 makes it a moot point since it makes the cost of additional HTTP requests so low. It sounds like someone's confused about what's going on or what's important to optimise.

They want the assets hidden, so wouldn't the proposed encryption that was discussed when C3 came out solve that anyway?

> They want to have the art assets hidden and reduce the amount of HTTP requests (the individual sprites I can easily encode as data URIs, but currently having to reverse the spritesheeting makes it a bit more cumbersome).

>

This makes no sense. Spritesheeting does reduce the number of HTTP requests. Besides, HTTP2 makes it a moot point since it makes the cost of additional HTTP requests so low. It sounds like someone's confused about what's going on or what's important to optimise.

The end result is a single HTML file, so it's only one HTTP request. I never claimed this to be optimizing, it is only to adhere to client wishes as I mentioned earlier.

Ashley I completely agree with you though that this cripples the project performance, but at least the client gets the desired result.

p.s. any response towards giving users some control over which assets are combined to which spritesheets? I tried to ask about it couple of times, and it would be really great to see. In C2, I'm able to do it based on the order of sprite object generation and animations, but I haven't so far found out a way to replicate it in C3.

Any plans on implementing this kind of feature? (e.g.a spritesheet group number as a variable for the sprite object, The logic could be with default value being 0 and then the spritesheet process works as it does currently, but anything else would be spritesheeted accordingly to the group number)?

p.s. any response towards giving users some control over which assets are combined to which spritesheets?

I've asked for this feature already. Possibly an automated method is coming for C3 based on this response. But probably only if more people ask for it as Ashley doesn't think its a major issue. I've stuck with C2 so that I can take advantage of one spritesheet per sprite.

>

> p.s. any response towards giving users some control over which assets are combined to which spritesheets?

>

I've asked for this feature already. Possibly an automated method is coming for C3 based on this response. But probably only if more people ask for it as Ashley doesn't think its a major issue. I've stuck with C2 so that I can take advantage of one spritesheet per sprite.

Ahh, so you're in the same boat as I am... for in-house projects still having to use C2.

For this specific client work, I preferred using C3 to support further development of it (we got the standard business license, although we're a startup). It's great that we no longer need jQuery, but I certainly hope that later on in the future we get a bit more control over spritesheeting.

The end result is a single HTML file, so it's only one HTTP request.

No way. I'd ask if they're joking, but it sounds like they mean it. Tell your client that is far slower to download, will use much more memory, and will be much slower to load. I am not kidding, that is a whole new level of deoptimisation beyond turning off spritesheets; inlining loads of binary files as strings is way less efficient.

As for spritesheet memory optimisation, we have dozens of critical things to be working on right now, and I have seen precisely zero cases where spritesheeting has caused memory problems in a game, so it's not a priority right now.

I am happy to see others requesting this, and I am very worried that future encryption will be forced instead of an option.

I use construct for making reskinnable games for advertising agencies. So all they have to do is overwrite the art assets and upload the game to their webserver.

So being able to organize the spritesheet's would be huge. Like placing all the UI stuff in one spreadsheet, that the customer most likely won't reskin, and game elements on another spritesheet that they would like to reskin.

I like the idea of encryption, but please make it an option, as it would otherwise put some people out of business.