I don't think it's a simple thing to just turn off spritesheets. Spritesheets are always power-of-two sized, and while WebGL 2+ supports non-power-of-two texture sizes, WebGL 1 does not. There's still enough WebGL 1 systems out there that I think if it just exported a bunch of non-power-of-two individal images then your game will be broken on a small percentage of systems, but enough that you'll get a lot of "game doesn't work" reports.

Then there's other issues like larger games losing the benefits of spritesheets could become significantly larger to download and significantly slower to load, and have a runtime performance hit too. It could be a massive deoptimisation for your game that slows things down even for players who don't want to mod anything and just play the stock game, which I think is an unfortunate trade-off.

Perhaps some of that can be mitigated in various ways, but it's complicated. Modding is a very large area if you want to go further to adding new kinds of objects, changing game logic, adding new kinds of level themes, etc. as well. I fear this may be one of these areas people say "just add A!" then "just add B!" then "just add C!" and then on for another 20 things over months/years.

Fair enough! I'll admit it's already possible for me to offer a set of in-game tools to the player to inject their own custom art and music and have those changes propagate through the game. I consider it a big hassle, but i guess turning off spritesheeting is equally or moreso a big hassle for Scirra.

Oh btw, to address your concerns with larger projects being slowed down by disabling spritesheeting; my suggestion was to have a bool in the export options to enable or disable based on the preferences of the developer. With enabled being the default option of course :)

I agree that those things would be a huge benefit, but I would be enormously grateful for merely disabling the automatic atlas creation when exporting. That would at least allow the users to change all that stuff manually and for it to not get lost across tiny version differences in the game.

It's also considerably more messy to have essentially two copies of every image in the project. One in a local folder (for modding) and the original in the image folder. Which also includes the annoyance of teaching the players to mod the modding folder images instead of the other images. And, not to mention, a ton of refactoring to a project that has hundreds of sprites and tiled bgs, and so on

You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

Not every object that has art in a construct project has the capacity to load from URL

Heyo! I submitted a suggestion and i would appreciate if y'all could have a look and perhaps upvote it. If the suggestion gets implemented, it would be an incredible step forward for modding construct games.

construct23.ideas.aha.io/ideas/C23-I-465

If y'all want to discuss the merits of this or suggest existing solutions, I'm all ears!

When exporting your project using Construct 3, the engine automatically merges art assets into shared sheets for memory considerations. That is nice except when you want to encourage modding in your game.

Modders will want to replace Shared-Sheet2.png with their art. That's all fine and good. But what happens if the developer releases an update that adds a single image into the project? It will likely break all the mods for the game.

This is because the engine will re-combine the art assets in the project into sheets without honouring the previous sheets. This causes a cascade of changes where nearly every sheet is a different art asset and mods that reference Shared-Sheet2.png are no longer referencing the same part of the game's art.

Currently, the only way to have users swap out the same sprite art across multiple versions is to give them access to the construct file and have them compile the game themselves. This isn't ideal. A simple boolean that disables the Shared-Sheet generation would be a saviour in this respect.

I orchestrated a different way of testing it. Spawned a bunch of semi transparent circles with sine behaviors until fps was consistantly below 50 then stopped and displayed object count. Looks like nw.js has a 7% performance reduction over running the game directly in chrome preview.

Not nearly as bad!

Just out of curiosity.. What are you doing in Animate that you cannot do in C3, since you own a C3 subscription already?

(The only thing I knew was video export)

It will hopefully by substantially cheaper because there are lots of things you can't do in animate that you CAN do in Construct. Not as much in the inverse direction/

Set Animation Frame to Array.At(X)

Make sure the content in Array.At(X) is an integer value. Alternatively you can add int(Array.At(X)) to ensure that the value is converted to an integer if possible.

madewithconstruct.com is a good place to start looking if you want to see awesome Construct creations.

My character runs around on a book. There is text that has to cover the entire playable area. See this trailer for more clarification.

youtube.com/watch

This is also why it's very inconvienant that the pixel rounding of text objects is not something i can turn off. On 1080p monitors the text objects all appear to be vibrating due to the rounding.

I've had to work around this by making my text into pngs and using sprite objects. Unfortunately...

Out of curiosity, is it more performant theoretically to have 4 text objects that are 2048x2048 versus one that is 4096x4096?