Ashley's Forum Posts

  • We have good support for exporting to Android using Crosswalk. I do not understand what the problem using the Intel XDK is - do you have any specific problems? It's simply a convenient way to get an APK built for you without having to install hundreds of megabytes of developer software. Crosswalk is an open-source library for Android (as is Ejecta), so if the Intel XDK ever started charging for use (which they have told me they have no plans to), then we could add a way to directly build an APK from the Crosswalk library itself, but that would probably be a lot more complicated than just clicking "build" in Intel's tool.

    For the record, our store refund policy is in our store terms & conditions: https://www.scirra.com/store/terms-and-conditions

  • sylva1n - those spikes are temporary, what's the usage on the flat parts of the graph? Spikes might come up as it's relying on a garbage-collection scheme for freeing memory, which it won't do until memory usage increases.

    — - WebGL mode did not run slower in my own tests, and is still faster than the Safari browser. Are you sure the performance difference does not come from using WebGL shaders? Do you have any examples that demonstrate the performance difference?

  • You only ever associate player objects with MyID, which is not correct, you need to associate them with the ID of the peer they represent. You also never associate the object initially in the layout with any peer. The multiplayer tutorial covers how to handle all of that correctly. Try starting with one of the templates and modifying it carefully.

  • CocoonJS does support WebStorage.

  • Yep, optimisation is often a waste of time. Rely on measurements with the profiler to direct your optimisation efforts, and only do it if necessary.

  • I still have no idea what this could be. I think VRAM is ruled out by small projects doing it, and V8 garbage collection is ruled out by the fact Chrome has the same javascript engine, but doesn't reproduce the problem. I think export-mode only is probably not actually the case - the export-time optimisations usually help improve performance and there's really absolutely nothing in the export process that could cause long pauses, so I feel it is more likely it is a sporadic issue that has not been observed in preview mode only by chance (perhaps because people spend less time in preview and more time in exported games?). 4 seconds is also an extraordinarily long pause for any local activity: not even garbage collection covering hundreds of megabytes of memory, or very large disk accesses, would take that long. It might even possibly somehow be a blocking network request.

    I would guess the most likely cause is the node.js component of node-webkit, since node-webkit is more or less identical to Chrome apart from in that regard, but that is out of our control and something the node-webkit developers should look at. It's also totally impractical to debug a sporadic issue that only reproduces after ~20min - debugging often involves running and testing the issue 10, 20, 30 times or more, and hours of sitting around watching a game does not sound like it would get anywhere. I think the best approach is to report the issue to the node-webkit bug tracker with (as always) as much information as you can possibly provide, and see what their view on it is.

    Node-webkit is also now two versions behind Chrome; it may be the latest version of Chrome has performance improvements which node-webkit will also get when it catches up.

  • I don't know why that would happen. The recent files list is remembered by the UI library so it's not our code.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Well, it looks like the device is out of memory, so you need to make your project use less memory. What is Construct 2 reporting as the estimated memory usage?

  • jayderyu - the Text object is not a DOM object. It's a pure canvas feature like Sprite.

    Sargas - if the contents of the Text object is not changing, it renders as fast as a normal Sprite. However changing the text causes re-flow of the text, and in WebGL mode a copy-to-texture which can be slow. Generally if you avoid changing text's contents every tick it's fine. Even if you need to keep changing text, just change it on a timer instead (e.g. once a second). Alternatively you can use a Sprite Font which never needs the possibly slow copy-to-texture that Text object needs to do when its contents changes.

  • No, two people cannot use the same license. See http://www.scirra.com/tutorials/57/how-construct-2-licenses-work

  • I don't think it's anything to do with Construct 2. AFAIK games run smoothly on other platforms, so it sounds like a node-webkit issue.

  • Are you sure you don't use any third party plugins/behaviors? A buggy third-party addon could cause this.

  • No, it previously threw an exception on audio.play() which I coded to just be caught and ignored so the entire game doesn't fail, but then the browser/app just quits. I guess the crash could be unrelated to audio, but I think it does work fine if you remove all audio playback.

  • Nothing, it looks like a straightforward coding mistake on their part. Maybe they call a function without checking it exists first.

  • Don't use the Windows Phone plugin. Just export a universal app for WP8.1+ and it will be able to play the .m4a files like IE usually can. WP8.0 has pretty poor HTML5 support so I'd recommend only targeting WP8.1+.

    I've been able to see crashes on WP8.1+ still from playing too many audio tracks, but you'd need to contact Microsoft about that, it's an IE bug.