Do event conditions early-out?

0 favourites
  • 8 posts
From the Asset Store
Very simple code without excess options (15 events for server and 11 events for client)
  • Hey,

    I just had a quick performance related question about the event system: do the conditions on an event "early out"?

    Say for example I have an event triggered by the following conditions:

    • MouseClick on Sprite
    • if someVariable = true
    • if someOtherVariable = true

    So logically, the event triggers when the mouse is clicked on a sprite object if someVariable and someOtherVariable are both true.

    If someVariable is false in my example, would construct bother to check the value of someOtherVariable, or will it be clever enough to early-out and skip that check?

    I ask because I have a couple of events with reasonably complicated conditions and I'm wondering if I should bother arranging the conditions in an order that could take advantage of an early-out to skip un-needed checks.

    I am aware that the performance impact would be fairly minimal, and that where possible it's better to design less complicated events or break things down to sub-events anyway, but small differences can add up on a mobile platform and I'd like to know if this is an area worth spending (and admittedly minimal amount of) effort on?

    Lastly, if conditions don't early-out, consider this a suggestion that if it is not overly difficult to make them do so they should! <img src="smileys/smiley1.gif" border="0" align="middle" />

    Thanks for your time! <img src="smileys/smiley1.gif" border="0" align="middle" />

  • By default logical operators in JavaScript early-out (more commonly called 'short circuiting'), so I can't see why Ashley would override that behaviour. As far as C2 is concerned I'm not sure. This would be easy enough to test.

    • If someVar = true And someOtherVar + 1 = true

    If someVar is false and it short circuits someOtherVar will not get incremented. If it doesn't short circuit someOtherVar will get incremented.

  • That is in fact the case - if you do a test with a simple check of a global variable first followed by a cpu intensive condition like checking if a thousand sprites are overlapping a thousand other sprites, the framerate only dips from the second condition when the global variable check is true, showing that the collision check is entirely skipped.

  • Conditions do early-out - there's no reason to waste CPU running conditions when the event is already known to be false!

    It would probably be difficult to measure a performance impact from rearranging conditions though - often rendering takes up a lot more processing than the game logic.

  • Thanks!

  • Apparently collision checking is something big to watch out for. I suppose then, you should arrange collision checks to be at the end?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Collision checks can be one of the most intensive conditions, but of course that depends on the number of objects and points involved. So yeah, if it doesn't disrupt the flow of logic, you might as well.

  • I asked about collision not long ago, basically 'collision' and 'overlap' are the same thing (except collision has a hidden "trigger once" next to it) except with 'overlap' since it is not a "trigger condition" you can place it further down a list of conditions so it's not checked as often.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)