Three questions:

• Is there a reasonable way to "hack" a Construct 2 project so that I can use custom spritesheets?
• @Ashley, would you ever consider giving us more options for the creation of sprite sheets within Construct 2?
• Do you think sprite sheet optimization beyond what Construct 2 already does is worth it for mobile?

So here's the deal: Construct 2 currently sacrifices some sprite sheet optimization in the interest of greater compatibility. For example, instead of creating larger more condensed sprite sheets, it creates one sprite sheet for each sprite. To my understanding, it does this primarily to support progress bar feedback. Since there is no way to tell how much of an individual image is downloaded, splitting sprite sheets up allows Construct 2 to count how many of them are loaded from the total, giving a more precise picture of the load progress.

This decision makes sense when considering that Construct 2 was made for HTML-5 games, which are typically "downloaded" rather than "loaded from disk". However, I believe many people are using the engine now primarily for mobile game development (like me). This means the games will be running on less performant GPUs, but will load much faster since they don't have to be downloaded. These lower-end GPUs could benefit from not having to swap textures as often as they would with multiple spritesheets, and the "progress-bar feedback" reasoning here is not as compelling as it is for browser games.

So for mobile-only developers, it would be nice to have the option to pack the sprite sheets manually, with the aid of tools like Texture Packer. Construct 2 games on mobile might consequently see lower memory usage, better GPU performance, and on the whole more native-like experiences.

Now, I do remember reading that Ashley was unable to measure any performance difference between using one giant spritesheet and using multiple ones. However, I don't think the test he used is always an accurate profiler of GPU performance, because the test averages the framerate as reported by the CPU. In my mobile game, despite a reported framerate that's generally 60 or higher, there is persistent stuttering and frame dropping that makes the game look bad. I hope it's just JIT compilation that will be fixed soon, but I've learned to choose skepticism over hope. It seems like there could be something crazy going on with the GPU here that the CPU doesn't seem to capture. That's why I don't completely trust this idea that sprite sheets make no difference. If there is room for optimization that could theoretically help GPU performance, I'd like to experiment with it.

What do you guys think?

I've looked in to this in the past and I think it's JIT compilation in the Javascript engine.

Ashley, If JIT compilation is truly the issue, what sorts of Construct 2 events would you recommend we use in a "compiler" layout to force code to get pre-compiled? Should we call functions we use in the game, create and destroy objects, make Touch conditions etc.? Could this technique even work to reduce the problem?

Wow, this might explain the micro-pauses I'm getting with my game on CocoonJS! Perhaps there is hope after all, since Ashley's theory seems pretty spot on.

If anyone is interested, I made a thread on Ludei's website, requesting them to also look into their compiler to see if they can fix the frame dropping. If you're also a "Cocooner" then please upvote the thread to show your interest in the issue.

And also, I made a simulation of what my simple bouncing square application looks like on my phone through CocoonJS. I have always assumed the stutter was simply garbage collection, but now I'm thinking it's a combination of that and synchronous compilation. Whatever it is, I hope it can be fixed soon!

What is your solution to the 15MB app size limitation?

I think it's 200mb with a premium account - plenty for a serious, medium-sized mobile game. And as far as I recall, when I wasn't a premium user it was 30mb, not 15mb.

I've been having some irritating frame stutter issues in my game using CocoonJS even though it shows me 58-60 FPS, which leads me to believe that garbage collection is the culprit, though I could be wrong. Regardless, my research led me to someone's open-source project called OwnGap, which though minimal, currently has touch input implemented. I have not yet tested this, but it seems like an impressive project that I figured was worthwhile mentioning to the Construct community, especially at this critical time when CocoonJS has been officially deprecated.

And here's my unrealistic dream which I'll include here for fun: if this is actually a viable export option, perhaps Ashley could get in touch with this programmer from the heavens and give us that long-awaited alternative for Android export that doesn't suck. Yes, wishful thinking on my part, but hope is what keeps us going sometimes

Yeah it doesn't make a bit of difference for me looks like

Thanks for the response.

Wow, I hate to be the guy that didn't read the post properly

Thanks for correcting me.

Just FYI, I think this topic is covered here: https://www.scirra.com/tutorials/556/un ... o-families

In an article I was reading, it made the following statement which I'd like further clarification on.

[quote:u727pkzp]

10) Scroll to is faster than moving eveyting

Rare situation but it happened to me. Don't move every object if you can scroll your view.

My infinite "runner" game currently uses very specialized scrolling. I have a family of objects called "Scrollable" which move downwards as I "scroll" upwards. Should I re-do the scrolling so that it moves the view instead? How much of a performance boost might this give, and why? Is it worth it (I'm using CocoonJS to port it to mobile)?

I guess the best workaround for neatness and improved maintainability is to define all functions in one event sheet, along with global constants to reference those function names. Whenever a function name has to change, simply make two changes - one to the trigger, and one to the global constant.

That doesn't seem too bad I guess.

I wonder if there would be any issues if Ashley revised "cf_fast_trigger" to allow for referenced constants. Isn't it essentially the same thing since it still restricts the name to a constant that is never going to change during run-time?

One obvious example for why allowing this is a good idea: one might use the Function trigger in multiple places throughout the code. Then, if it comes time to rename the function, it must be renamed everywhere, including all calls to that function. If a constant was being used in the condition and in the calls, renaming wouldn't be an issue.

Not sure whether to call this a bug or not, but it's definitely counter intuitive enough to me that it seems like it could belong here

Problem Description

On Function condition won't let me use a constant value as a function name.

Steps to Reproduce Bug

• In a new project, add the Function object.
• Create a global constant text with an arbitrary name.
• Attempt to create an On Function condition referencing the global constant as the function name.

Observed Result

We get a message saying "Parameter must be constant".

Expected Result

I would expect that referencing a global constant qualifies as the parameter being constant.

Construct 2 Version ID

r170.