Still best practice? Always have " is overlapping" as first condition

0 favourites
  • 12 posts
From the Asset Store
Units do not overlap each other and use different ways if there are several free ways.
  • Over a decade ago in C2 there was a new thing called "collision cells", and in order to use them you had to have your "overlapping" condition be first in the top level event (not as a subevent).

    It can feel counterintuitive, because often we prefer to have other filtering conditions before doing something as expensive as a collision check. But apparently it was worth the trade off.

    I couldn't find anything about this in C3 manual, is this still the best practice?

    Here's the old blog post that explains the feature: construct.net/en/blogs/ashleys-blog-2/collision-cell-optimisation-914

  • I believe the advice still stands: collision cells can't be used once any other picking has happened, so it may be best for any collision conditions to come first and then any other conditions to further filter from there. However as ever the best way to get the right answer for your project is to measure it.

  • Thank you for clarifying that it's still a thing!

    I don't think I'm good at making performance tests, because when I tried doing it I get better performance when it was a subevent. 😅 So I'll just have to trust you.

  • Weird, I just tested with 2000 sprite instances, and I'm getting the same number of collision checks and the same fps with "Is overlapping" being the first, second or only condition in the event.

  • dop2000 thanks for testing too! Maybe we have to set the collision cell size first? Did you have an action doing that?

    Perhaps a manual entry could help to explain this concept.

  • So I tested again and here are the results:

    There are 1000 instances of sprite A and 1000 instances of sprite B. Animation frame is set to 1 for half of them.

    250K collision checks per tick - collision cells are working.

    125K collision checks - collision cells are working. And it's more efficient because we eliminate half of A instances.

    500K collision checks - collision cells are NOT working.

    Test project:

    dropbox.com/scl/fi/u8tlp28lh0fj87yh1n6n9/coll_cell_test.c3p

  • that is an interesting find dop!

    It seems like it matters which instance is first in the is overlapping check, so Sprite2 is frame 0, Sprite 2 is overlapping Sprite1 works too

  • fantastic thanks everyone!

    dop2000 when I used the action to set collision cell size to 10x10 it reduces the checks down from 125000 to 800. So it seems it does that cells help a lot to reduce checks!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I've never thought about this, I didn't even know that was a thing. Interesting.

  • when I used the action to set collision cell size to 10x10 it reduces the checks down from 125000 to 800.

    This is insane! I wonder if collision checks actually work correctly with such heavy optimization.

    Ashley Could you comment? 125000 to 800 seems too good to be true.

  • keep in mind that with very small collision cells (and large layouts) the overhead of the collision cells themselves increases, so only comparing collision checks isn't the whole story.

  • Ashley Could you comment? 125000 to 800 seems too good to be true.

    Small collision cells will indeed further reduce the number of collision checks. But everything is a trade-off: small collision cells can use a lot more memory for large layouts, add a lot of overhead when there are many fast-moving objects, and probably have a lot more overhead when using very large objects which span lots of collision cells. As ever with performance, you should make measurements on real-world projects; don't just assume that a certain collision cells size is always the correct one.

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