Ashley's Forum Posts

  • Closing as won't fix: the problem is with the browser, not C2.

    In Chrome for iOS, it correctly triggers 'On suspend' and 'On resume' when switching tabs, but not when returning to the home screen and going back (which Safari does correctly). Old Android stock browsers simply don't support the Page Visibility API which is the way the browser tells C2 if the page has been hidden, so it can't be supported. It should work in Chrome for Android though.

  • Thanks, should be fixed in the next beta.

  • Closing, please see the bug report requirements

  • I can't reproduce the problem. In the provided .capx, I can zoom in and out and select objects and everything appears correctly. I think this is probably a graphics driver bug, are your graphics drivers up to date?

  • Closing as by design. One unexpected aspect of OR blocks is, in order for them to work correctly at all, they must be able to run with possibly zero instances selected for a type. "Layer 1" is invisible and it's in an OR block so the event is definitely going to run its actions based off that alone. The next condition tests for sprites which have var = 1, and none do. So the event engine picks zero of those instances and proceeds to run the actions. The actions run for all picked instances, so the Sprite action runs zero times and Sprite2 was not referenced so runs for all instances (once in this case).

    Note if you saw Sprite rotating, it would contradict the fact you have a condition that says it should not rotate.

  • Closing as not a bug, this is more of a feature request.

  • In C2 it's basically undefined. It picks an arbitrary instance (read: random) to use as the default instance in the editor. It could revert to using the default settings every time, but this is usually worse, e.g. if you have 3 large red text instances, and you drag and drop in a new one, you probably don't want it to revert to small black text - picking any of the existing objects to clone is more sensible. One workaround is to adjust your workflow so you always copy and paste or ctrl+drag an instance, so the editor knows which one you want to copy from.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Probably not because it's a perfect candidate to offload on to a different CPU core and run in parallel. Maybe on a single core system, or a really badly designed browser/OS which can't parallelise it, but I think all modern systems are fine.

  • See troubleshooting Construct 2's preview server.

    You really, really should upgrade from XP. It's well past Microsoft's own support, so it's becoming increasingly insecure; browser makers will sooner or later drop XP support too (so you'll end up with a frozen, aging version of Chrome at some point for example, and of course you cannot test IE11 or Edge with their radical changes); we ourselves may eventually drop support for XP because it's increasingly difficult to support such old systems.

  • It does, i tried. I got hundreds objects, even if i check every 10 seconds, the lag caused by the evet is there. Because i need to put For Each object -> create test sprite -> test sprite overlaps/dont overlap. Basically, it has to repeat the event for every object.

    (Emphasis added)

    Creating a sprite is a far more performance intensive than checking for an overlap! Instead you should just have one instance of a 1x1 sprite which you simply position to the image point, then test for overlap with. If you are just moving around one instance of the "detector" sprite and not constantly creating and destroying them, it should be perfectly performant.

  • From ***MUST READ FIRST!*** Bug report requirements:

    [quote:2kh0zkm3]Why haven't you responded to my bug report yet?

    We do look at every report, but developer and release schedules mean we may not get round to it immediately. Please allow a few weeks for it to be investigated. If you are waiting, you can improve the chance it is resolved when a developer does get round to it by carefully reviewing these guidelines and providing as much useful information about the problem as possible. If you are missing anything, you may end up waiting a few weeks for a reply simply asking for the missing information, and then you're waiting again.

    Emphasis added. Please be patient. Two or three working days is not a reasonable amount of time to expect a bug report to be investigated.

  • Events are always evaluated sequentially. The only way you can run an event outside of top-to-bottom order is with a trigger (such as a function call). Within each event, the conditions are tested from top to bottom. If they are all true, and only after all conditions have been tested, the actions are then run top to bottom. It's pretty simple, it all runs in order!

  • If you need real-world examples of why and how this would be useful, just say the word.

    I always need that. That is mandatory. I have no evidence that the sampling mode impacts performance in any meaningful way. Can you provide data that backs up this assumption/assertion?

  • paradine - it sounds like most of your criticism is centered exclusively on Crosswalk. It had a bug recently which could reduce performance, but it should be improved in Crosswalk 14. There's no reason Crosswalk can't be as fast as the browser (it is a browser), so it should be able to produce identical results to your HTML export which appears to have excellent performance, so if it can be that fast, what do we need a native exporter for? We're not going to work on a 12-18month project just to work around a passing bug in Crosswalk.

  • Well, most games that use physics, particles and pathfinding are CPU-bottlenecked.

    If you're using asm.js physics, there's not much more that can be done to make it faster - it should already be about as fast as physics in a native engine. Pathfinding runs in a web worker in parallel to the game so even if it's slow (and generally it's still reasonably fast) it should have no impact on the framerate. Particles are already highly optimised and even very large effects should run well (this demo runs nicely on many of the mobile devices we have in our office, with ~800 particles).