The aim of the reputation system is to emphasise quality, not quantity, of contributions. So we specifically want to avoid "quick-fix" ways to get loads of rep.
As always, my answer is the same...
If you can measure a performance difference: yes, it matters
If you can't measure a performance difference: no, it doesn't matter
You are worrying about the wrong things.
The things that matter are documented.
If it's a simple free game there's always publishing it to the web, where it's the download size only. iOS 8+ has no file size overhead with PhoneGap and from Android L you can get Crosswalk-like performance and features with PhoneGap and no extra filesize overhead, so it's basically a temporary solution to support older Android 4.0-4.4 devices and will be unnecessary eventually. Until then I think it's worth the extra file size overhead, which is to bundle the Chromium browser engine with the game for maximum performance and best feature support on devices which have otherwise poor built-in browser support.
Closing as by design, it's a quirk of the engine. Duplicate report with more explanation here: https://www.scirra.com/forum/sprite-object-is-not-destroyed-properly_t116572
Thanks, good catch. Should be fixed in the next build.
It looks like it's working correctly. By turning 'parallax in editor' on, you are making the editor display it like it does at runtime, and objects on a parallax 0,0 layer are fixed in the viewport. Since the editor viewport is a different size to the runtime viewport, it doesn't line up the same way. I can't see that this has anything to do with global layers either (it works the same - correctly - with global off). Are you sure it worked differently in r178?
Thanks, good catch. Should be fixed in next build.
Develop games in your browser. Powerful, performant & highly capable.
A Moto E goes for $119 and has 4GB of storage. 60mb represents about 1.4% of its storage space. Are you sure that's a problem? BTW as of Android L you'll be able to publish with PhoneGap, which should work just as well as Crosswalk and without any extra filesize overhead.
Even if we supported it, without a full DOM, Web Audio API, WebRTC etc. etc. it will be an ongoing compatibility nightmare. A big factor in dropping CocoonJS support was the perpetual support headache of users running in to those same missing features again and again. So no, if it is missing such major features, I don't want to support it.
These kinds of questions come up from time to time, so instead of answering repeatedly on the forum I wrote a new manual entry covering memory use:
https://www.scirra.com/manual/183/memory-usage
All the form control plugins do is create a HTML element and float it above the canvas. In theory you can create any HTML content and float it above the canvas in the same way. Take a look at the implementation to those plugins to see how it's done.
Member since 21 May, 2007 Last online 27 Oct, 2026
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.