Ashley's Forum Posts

  • I don't think features that can be implemented in a single event really deserve to be an entire behavior. The Scroll To behavior is mainly for beginners, so you can set up something like a scrolling jump-and-run without any events at all.

  • 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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • No, I don't think a cache is a good idea. I previously considered it to keep it compatible with WebStorage, but decided not to for two reasons:

    • performance: the speed at which you can read and write values to the actual storage is proportional to the total amount of data in storage. So suppose you had 300mb of data in storage, and your app wants to read a single number, change it, then write the number back (e.g. a simple play count). That involves reading 300mb of data, plucking out a single value, then writing 300mb of data again.
    • it's always going to be unreliable: you can't really solve the problem of how to write the cache to the actual storage. At any time the user could just close the browser, and then there is no opportunity to do an asynchronous write to storage, and the changes in the cache are lost. There aren't any good options to mitigate that. Writing storage every time it changes will completely hammer performance (imagine writing 300mb every time any key changes), and throttling it to a timer means you can still lose data (e.g. if you write every minute, you can still lose up to a minute's worth of data).

    Besides you can do this yourself already if you really want to: just store the JSON data of a dictionary object in storage - but you'll probably have subtle and frustrating issues with data being lost randomly.

    I agree "Then" is a poor name... I think I'll go with "Next" for the time being.

    Reading Animmaniac's post, I think actually it could be a good idea to make "Next" act like "All completed", so it doesn't have the one-async-action limitation. The problem is then how to access multiple storage keys, but I think it could load multiple keys at once by a comma-separated list, e.g.:

    • Get item "level1score,level2score,level3score"

    Next

    • Set level1score to LocalStorage.ItemValue("level1score")
    • Set level2score to LocalStorage.ItemValue("level2score")
    • Set level3score to LocalStorage.ItemValue("level3score")

    This could of course use three separate "Get item" actions, but I think it's clearer with a comma-separated list: there's only one trigger that fires for the one action, instead of three triggers firing and "Next" only really triggering on the third, which could make it tricky to identify which values should be available to the ItemValue expression (since it should only make available values that the trigger is firing for).

  • If you want me to take a look send your .capx over to with an overview of the problem areas/what to do and I'll take a look. I may not be able to do this for everyone since we have thousands of users, but hopefully a few real-world examples will allow me to make some engine improvements if necessary.