Ashley's Forum Posts

  • Added a note in the example for the next build.

  • Closing as not a bug. Please report following the guidelines if you can find anything specific that does not work when outside of that range.

  • Closing as won't fix: I don't see why you would want to set an animation and stop it immediately afterwards in an "on animation finished" trigger. Since the actions don't seem to make sense I'm not going to investigate this. It appears there are good alternatives already proposed here.

  • Closing as not a bug: as per the normal way conditions work, they filter down the picked objects. A later condition cannot pick objects that are not already picked, with the sole exception of "pick all".

    Therefore as your events are, the "pick by UID" condition can only pick the object meeting the "is overlapping" condition, and no others.

  • Aurel - are you using the latest C2 beta? We fixed an issue with Mac NW.js exports since the last stable.

  • Construct 2 already spritesheets everything on export so the question of what you do in the editor is pretty irrelevant. FWIW, when I was developing the spritesheet feature, I could not measure any performance impact either way with using no spritesheets, per-object spritesheets, or large global spritesheets, so as far as I am aware it makes absolutely no difference at all, which is unsurprising since questions like this are often a waste of time.

  • I'd point out that the performance of Box2D physics is significantly determined by the number of velocity and position iterations, which currently default to 8 velocity iterations and 3 position iterations. This is the tradeoff between CPU work and physics accuracy. Comparing it to another physics engine is difficult, because it could use a default equivalent to say 4 & 2 iterations, making it less accurate but less CPU intensive. You can probably turn down the iteration count until Box2D is faster than another engine, but then the accuracy of the physics simulation suffers, and it is probably difficult to compare the accuracy of two different physics engines.

    Further the C2 physics engine has features that involve adding callbacks to the physics engine which probably have a small performance impact - disable collisions requires collision callbacks, and the physics engine is also able to fire normal 'On collision' events upon physics collisions (which wouldn't otherwise happen). If another physics engine does not support these features, it has an unfair performance advantage since it does not have to do the same work.

    We have a benchmark (based around circle collision shapes, which I think makes the difference) which clearly shows asm.js physics is about 3x faster than box2dweb in that case. So even if in other cases asm.js is about the same, if sometimes it's that much faster, it's definitely worth having.

    We aim by the next stable release to have asm.js physics as the default.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You just learned the hard way why you should keep your work safe with Construct 2's backup options.

    "De-exporting" is deliberately made as hard as possible to prevent people's work being reverse engineered, which is a significant feature for a lot of people. I am not aware of any cases where any exported project has been usefully de-exported. We also do not have any internal tools to do it (which I don't know how we could write anyway since the obfuscater is pretty effective).

  • I checked the performance of 0.12.0-alpha3 before release and it was perfectly smooth here - hardly a jank visible.

    Staying on old versions is not really a viable long-term strategy, since you will not get any of the new features or other performance improvements of future Chromium updates.

  • I tweeted that issue since they're being slow with it. Generally that gets a bunch more stars!

    I prefer to give Google time to fix issues, but if they're outstanding for a couple of months, don't show much activity, and are serious impact, then I will tweet/facebook/g+ them to get them some more attention. That worked well with the Chrome v-sync issue too. It's not something that I think is generally necessary though.

  • I'd provide a demo and file it on crbug.com so the Chrome developers can take a look. I think you're right that given Firefox for Android does not have the same latency, it must be Chrome and not Android or C2.

  • Construct 2's engine doesn't add any latency, so it must be in Chrome or the Android OS. Which version of Android is it? I think the latest Android updates have significantly reworked the audio engine in the OS. I've never noticed much latency with our test devices either (Nexus 5, Nexus 9, Moto X) so maybe it depends on the device too?

  • It's how the offline cache works (more info in that link)

  • You shouldn't use lerp with angles, because it isn't aware of cycles. See anglelerp. I don't think lerping is the correct way to do this anyway, since you basically want the rotate behavior with an acceleration, which doesn't involve any lerping.

    FYI see also Using lerp with delta-time.