You're looking at the asm.js compiled version of the Box2d physics engine, which was machine-compiled from the source C++ code, so it's not going to make much sense.

Between C3 development and C2 maintenance I'm pretty busy at the moment, please allow me a couple of weeks to get round to those .capxs.

How is it that people making basic 2D games with three objects, from what I ready correctly, is getting 1FPS on mobile?

I have still not seen any actual evidence for this. I regularly run performance tests on mobile like sbperftest and particles, and they often run close to 60 FPS on a range of mobile devices. I wrote about my frustration over this earlier in the thread: so far people have talked about games that run at 1 FPS, but not provided any way for me to do anything about it, such as by providing a .capx.

You also talk about audio issues: I am not aware of any ongoing audio issues, so please file bugs so I can investigate, otherwise there is simply nothing I can do. Everything I have seen is that audio works fine across all platforms, perhaps except for some bugs in the latest beta releases (but that's what beta releases are for, to work out issues that arise from changes before they make the stable channel).

so why do games wrapped with CocoonJS Canvas+ are faster than games wrapped with Crosswalk?

I don't know, it's a closed source engine. Canvas+ was broken in a lot of ways, so perhaps they took shortcuts that broke things. Our experience with Construct Classic firmly proved that it is far better to have a slightly slower engine that works correctly, than a faster one that breaks. Reliability is essential, and it's often possible to optimise things at the expense of reliability, which is something that happened in Classic, and it wouldn't surprise me if the same thing happened with Canvas+.

[quote:1vrm8pl9]and why even the simpliest projects can't work 100% smooth in Crosswalk?

Probably because of the recent bug, which is not a fundamental issue with C2, its engine, HTML5 or anything other than the Chromium browser engine, which is constantly being worked on and should be fixed at some point.

It's hard for me to respond any more because I feel like a lot of what I say is being ignored.

WebGL is basically a thin layer over OpenGL: even from a HTML5 game, it makes almost identical use of OpenGL and the GPU as a native app. Many complaints we see about performance are in fact bottlenecked on the GPU, so a native app would perform identically. Native apps can improve CPU-side performance, but it needs measurements to prove it, and then there's still a lot of scope to improve the events or engine. And yet people write the most extraordinarily critical posts saying we should drop everything and make native exporters, without addressing this point. I could perhaps consider and discuss the matter if it was about CPU performance and how the overhead of the Javascript language is too much, but the impression I get is this is rarely the problem with real games. Even if it is a big problem which I've missed, there are other good alternatives, like writing the core engine in asm.js. So when people demand native exporters while ignoring these points, I am not at all persuaded in the slightest.

The thread then gets muddied with a bunch of other topics, like whether or not we'll support 3D, or random bug reports, or whether the latest beta release works. I don't think it's relevant here and it's confusing to throw this in to the mix, so I won't answer it here - start a new thread if you want to discuss them (and on the topic of 3D, I recommend spending a fair bit of time searching the forum first so you don't repeat what has been asked several times before).

Now, I know Chrome kind of sucks right now, and people are sick of the "wait and see" point of view. But the fact is it was working very well fairly recently, which I think proves that there is no fundamental issue with the Construct 2 engine or HTML5 itself in general: it's Chrome that is letting us down right now. I am very frustrated by this, as are a lot of you. However we don't face any good options right now. Given I don't believe there is anything fundamentally wrong with our engine, other browsers work well, HTML5 is always improving, and Google are aware of and actively working on fixing the issues, it seems to me to be short sighted to use this as a reason to ditch an already highly developed and effective engine which has been in active development for years, then start again from zero with a bunch of other technologies. I am especially skeptical of people who then recommend we use other third party technologies to make our engine cross-platform; what makes you think there won't be issues with them that screw up games as well? Or the other alternative is to hand-code our own cross-platform engine, which is a huge amount of work and ongoing maintenance. We would have little time to spare for the editor if we took that on, and meanwhile other users (and even some in this thread) are demanding further improvements to the editor itself as well. Things may suck right now, but I don't see any better options, and I still think HTML5 has a very bright future.

Also, believe it or not, the feedback we got from users when we supported exporting to CocoonJS (Canvas+) was even worse than the feedback in this thread, so I really can't see it helping to bring it back! Maybe it was a different set of users, but still, we really had an awful time with it and I got the message *loud and clear* that it wasn't good enough, hence our move to Crosswalk. FWIW, Intel are working on patching the OpenSSL issue with Crosswalk 7, so there should be a viable fallback to a working version to help mitigate Crosswalk problems in the short term. (The OpenSSL issue really made this worse than it needed to be - bad luck I guess.)

I spend a lot of time thinking about threads like this and our options to deal with the kinds of issue raises, but on a lot of fronts I don't think people are giving fair consideration to the entire topic (e.g. how a native engine won't speed up GPU-bottlenecked games). I keep putting the same points over and over, and I don't see many people really taking it on board, they just keep posting the same views again without addressing those points. I don't know what to do about that. I don't want to stop replying to people's posts - I expect to be criticized for poor customer service/ignoring customers if I do. But I wonder if there's any way of trying to move the conversation onwards instead of going in circles?

No, the operating system only updates the mouse at a certain frequency, and it's not possible to get it any faster. To solve this you have to step the position between the current mouse position and the last mouse position, simulating as if the mouse had really moved in small steps between those two points.

This proposed schema looks like many of the modern key-value storage schemas, which don't truly commit the data to disk until some time later, hence the term "eventually consistent".

These systems generally last the lifetime of the system and have a special opportunity to write data on system shutdown, meaning data is only at risk in the event of a system crash or power loss. Browser tabs can be closed at any instant without warning, and there's no guarantee anything async you start when closing a tab will actually be completed (since the browser is probably going to cancel everything the tab was doing). This makes it difficult to build an eventually-consistent system, since you either have to go back to really writing data every time you set something, or keep writing data on an arbitrary time interval and risk losing data since the last interval. Random data loss is not acceptable for a storage plugin.

So I don't think this kind of thing belongs in the plugin itself - but you can make such systems if you wish by saving/loading entire Dictionary objects (or other kinds of data stores) to a single Local Storage key.

rexrainbow - but it's confusing if the object looks like it is setting a value synchronously, but has only really cached it and it needs to be written asynchronously. For the caching system to perform well, you'd also have to have a per-key asynchronous write action. So to *really* write a value, you'd still need to do this:

• Set "myKey" to "myValue" (only writes to cache)
• Write "myKey" (writes for real and is asynchronous)

On "myKey" set

• (actions to run when done)

This is even more complicated than the current system and is confusing to beginners since setting a local storage value does not actually persist it anywhere. If you want this, just implement a cache yourself: read and write to global variables, the Dictionary object, or anything else, and then write with Local Storage to save it.

rexrainbow - but you still thrash the storage or lose data if you keep a cache in memory.

BasicTribe - I just don't know what to do! I have asked for a .capx and performance measurements, so I can do testing, profiling and comparisons on a range of mobile devices in our office. You wrote a very long post but did not include anything I can test on mobile: only compiled versions of a desktop game (which didn't seem to be interactive, but otherwise ran fine), and screenshots and a video, which aren't helpful for me (I need to be able to run profiles and test on mobile devices). So I really wanted to try and help by examining your project but you don't seem to want to cooperate. I regularly test a wide range of devices and I have never seen such severe performance issues as you describe. This is what I was talking about: people complain bitterly and make it impossible for me to help. What am I supposed to do about this?

Instead of a back to front renderer we need a front to back renderer

I've investigated this, but it's very difficult. Any image which contains a single pixel which does not have an alpha of either 0% or 100% cannot be drawn front-to-back, since its correct rendering depends on being rendered on top of the things underneath it. If a project contains mostly images which have alpha, then a front-to-back renderer will still be forced to render back-to-front. Even a single image with alpha will interrupt the front-to-back flow, forcing it to render back-to-front everything which that image depends on. This is very complicated!

3D games do use front-to-back rendering which is one reason they can run so well in comparison to 2D games. A well-designed 3D game can actually use a lot less fillrate than a 2D game. The fact 2D games very commonly use alpha blending in images is quite a difficulty.

Are the local storage datas deleted if the user empties the cache of his phone, as it was the case with the webstorage?

I think it's the same as with WebStorage. Stored data and the browser cache are two different things. The cache is to store online resources locally to avoid having to request them multiple times, but if it goes missing from the cache it will request it online again. Offline data like IndexedDB is not part of that process. I think Chrome clears offline data if you also clear cookies, and Firefox has a separate "Offline website data" checkbox to clear, so I guess it depends on the browser. It's definitely not in the cache though.

[quote:1mufp55o]Are the datas loaded in the chronological order?

Not necessarily. In theory the triggers could fire in a different order to the actions you used. If you have 150 small values which are always read and written at the same time, perhaps you could just use a Dictionary object and read and write it all as JSON data. That won't scale well for very large amounts of data though (in to the megabytes).

I set a value into webstorage every tick, it works fine.

But in local storage, the hard disk rotates always with big noise.

You should never do this with any storage mechanism. Other browsers might have thrashed the hard disk with the webstorage method too. Only write data when you need to!

Why can't Construct 2 handle this "On item get" trigger automatically ?

I am aware it involves more events with the new system, and I'm trying to come up with something to solve this and make it easier while preserving the async feature. See this thread: https://www.scirra.com/forum/idea-make-async-easier-with-quot-then-quot-event_t128870

[quote:1mufp55o]"Oooo with the new *parallel* processing, things will be faster" and all that crap.

Well, lots of other users wonder why C2 doesn't have more parallel features that can make use of multiple cores to improve performance. Jank (small pauses during games) is also a big problem for a lot of people. This new async storage plugin allows for parallel processing and reduced jank. If you don't like that then I don't know what we can do, we just can't win, someone will always be unhappy either way!

You can of course just keep using WebStorage for existing projects. You are not *required* to update, we just suggest that it is a good idea if you can. If you have hundreds of values and a huge project depending on complex usage of WebStorage, maybe you could just leave it, and use Local Storage for your next project. The decision is up to you, but transitioning to Local Storage is simply recommended, not mandatory.

matrixreal - Ejecta support has been deprecated and is no longer being maintained. We recommend you move to Cordova. See: https://www.scirra.com/blog/154/evolving-construct-2s-export-options

Closing as this forum is for bug reports not feature requests - please post to Construct 2 General for feature requests.

The Cordova plugin you identified is commercial and has a fee to use it, so we'd prefer not to use it. Note we have the Javascript SDK so you can integrate features yourself, you don't have to wait for us to do it.