Collision cells, Hit or miss?

0 favourites
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
  • The introduction of collision cells to increase performance was more than welcome, as optimised as C2 is "brute force" collision checking in a frame rate undulating browser environment, is a bottle neck on many projects...

    Unfortunately I did not get the performance gains I had hoped for, in fact I got a drop in performance, despite my game being pretty much a perfect fit as far as I can tell, breaking none of the Caveats "many static instances, same type, same none parallax layer"

    Even reworking events removing "focusing" collision checks moving collisions to top level ect, did not help...

    I find it difficult to believe that C2 sizing the cells automatically can be optimal for each and every project, and surely if the cells are unused due to caveats, the fact it has checked for them, will give a performance drop overall?

    The caveats, can be difficult to track in a complex event sheet with many objects involved, maybe I have missed something? and that's half the problem.

    I am curious if Cell sizing options or a collision cells off option, would allow fine tuning of collision check heavy games, I would certainly like the option...

    So my question is, has anybody else gained or lost performance, in games that were in development prior to the introduction of collision cells?

  • If your project is not bottlenecked on collisions it won't have any effect at all. What does the debugger profiler/system performance stats tell you? Is the performance difference the same across all browsers?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Maybe this as come across as a complaint, but actually I am really impressed with C2 performance overall...

    At the moment I am stress testing, running R153 At fullscreen 1024x768 it's pushing 169 meg of video ram with average 900 objects in the layout, hitting anything from 200-1000 poly checks per tick! CPU average 35%-40%

    In chrome I'm getting a consistent 50-60 FPS, node webkit rarely drops below 60, firefox struggles at 15-20 FPS.

    Not bad, In a browser environment on a seven year old system running windows XP, fitted with an ATI radeon 3400 graphics card...

    What I don't get is why exactly the same game, after updating to a C2 build that uses collision cells loses me 20 FPS on chrome 10 FPS on Node and Firefox sits at 10 FPS but still functions...just.

    If the cells are not suited to My game, "Brute force" is fine by me, but I could just do without the performance drop.

    I did notice that in recent C2 versions the poly checks per tick can rise by a good few hundred and only 1 cell ever seems to move, but that's in my brute force optimised build, I gave up on the cells weeks ago...

  • I haven't done any load testing yet, but that's pretty weird. The collision cells should have a very minimal performance loss. These question may help narrow the problem.

    • In your build, are you having all your objects randomly placed in the window? (as opposed to clumped up in one small area)
    • How large are your objects?
    • By "brute force optimized" build, do you just mean that all the objects have rectangular/square collision bounding boxes? Or is there more?
  • danialgoodwin I was under the impression the collision cells were a performance enhancing feature, so minimal is too much...

    Objects are a mix of random, player placed and static, but mostly static after being randomly placed at start of layout not sure that's relevant as most object in any project would be similar...

    objects again a mix but pretty small 16x16 the most prevalent objects, that is probably why I can get away with so many collision checks per sec...

    By "brute force optimised" I mean, I have not edited My event sheet, to ensure I do not break any of the caveats, required for the collision cell performance gain.

    Cheers for feedback.

    So nobody has gained or lost performance since collision cells were introduced?... Kinda odd...

  • I found no difference, was optimistic for potential performance gains but nope.

  • danialgoodwin I was under the impression the collision cells were a performance enhancing feature, so minimal is too much...

    I should clarify myself. From the way I understand collision cells, it takes a little bit of overhead to have, but theoretically (and most of the time) you won't notice the very slight drawback because the benefits are much greater.

    Each of those questions I asked provided a use case where there could potentially be more work required for using collision cells rather than using only brute force.

    Maybe you could share your simplified load-testing CAPX? I wouldn't mind running it to test my computer.

  • Cell checking shouldn't result in a performance loss at all , on the worst case , the performance shouldn't go lower than the "brute force" approach .

    Could you give us a bit more details

  • Collision cells, by their design, should not affect the number of poly checks. If you find it changes it's hard to comment further without a .capx.

  • For my particular game, on all but one layout my collision checks dropped from an average of 60,000-90,000 to around 5,000. That is a huge difference. I only have one layout now that still gets over 40000 collision checks and I can't figure out why for the life of me. But overall it has made for a huge boost in performance.

  • To the OP just to clear up the subject. Your reporting 500-1000 collision checks. That's good less the better if you can get away with it. however Performance boost isn't really magical situation. Even when one element is improved in speed doesn't make the entire game suddenly work better. It really depends on the stress of the game on the area at hand.

    We know that renderering is slow. If I have 60fps with just 10 small objects and say 20fps with 3000 objects. When the performance comes in and and the 3000 objects can now run at 60fps doesn't suddenly make the 10 small objects run at 300fps.

    The same rule applies collision checks. Sure there is a performance gain, but only in situations where collisions were slowing down the system when the time taken is more than 0.015ms(time of 1 frame).

    500-1000 collision checks isn't going to hang up your CPU. Where as BluePhaze 50+k collision checks will see a vast improvement.

    Since you seem to be bottled necked it's not collision checks that causing the performance problem. Also I'm not sure, but I though collision cells came in after r153. I could be wrong, but it's not really the point of the post.

    My suggestion is to check the debugger and find out what's bogging down your game.

  • Seems the general consensus is that all is fine in collision cell land...

    Maybe it's just a coincidence that my game is NOT bottle necked, until I update, and my particular mix of events is unique in some way...

  • Like Ashley said, there's really nothing anyone here can do for you, unless you provide a Capx that can be tested by us.

  • <sound of head hitting desk>

  • I have also experienced a Very noticeable decrease in performance after updating to collision cells. I have reverted back to an earlier version of Construct 2 as my permanent working version until it gets fixed or improved...

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