making use of collision cells

Is there a way to get the instances overlapping a point in scripting that makes use of collision cells and so doesn't require to loop over all instances?

This issue really makes it hard for me to do performant js without having to implement my own Quadtree/Collision cells.

The example projects seem to loop over all instances, which is fine for the limited scope of the examples but would not work out well for projects with larger levels and lots of instances.

Implementing my own Quadtree on top sounds a bit overkill as there already is a collision cells system.

Have you run into performance issues already? I have a feeling you might be overthinking this.

The example projects seem to loop over all instances, which is fine for the limited scope of the examples but would not work out well for projects with larger levels and lots of instances.

...

Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering

Quote From: construct.net/en/blogs/construct-official-blog-1/optimisation-dont-waste-time-768

Yes, you even quoted where I described the case, any system that needs to check collision against many instances will run very badly without collision cells as they have to loop over each instance which can quickly go up to thousand and thousands of checks per tick, for example 128*128 = 16.384.

I wrote this after I tried rewriting a system in js with the intention to increase performance, but instead I actually made performance way worse as I couldn't use collision cells. Sure I guess I could create my own system, but it feels redundant if there is already one in the engine that also already has its own overhead of being created and updated.

I'm not sure you are aware, but behaviors and is overlapping on collision events make use of collision cells (unless you pick beforehand). It's just that js doesn't allow accessing the build in collision cells.

Yes, I'm aware that the amount of collision checks can add up quickly, but a high number doesn't always result in poor performance. In the screenshot below, I have 19,317 checks per tick but still have 60fps.

Which is why I asked if you actually saw poor performance from using the built-in behaviors and event triggers/checks and looping through instances, as you mentioned that they do in the tutorials.

I believe that the people behind Construct are good developers. I'm a JavaScript developer myself but have read some of the articles about things Construct does under the hood and realized they have way more expertise than me in a lot of the areas relating to making a game engine. What am I saying? I trust them. If the engine has built in collision detection - I trust that it is the optimal way, and a lot better than I could create in a couple of days.

^That blurb might feel like a tangent - but that is what I meant by the "you might be overthinking it" bit

Also, the original ask of checking collisions without having to loop over all instances - from a programming perspective, I'm not sure how that is possible, ha. You can't get something from nothing - not sure what other way you could start from other than an array of objects and at minimum filtering the array.

So I'd probably start with setting up the project as recommended - like as you see in the example projects - and sharing the performance stats. Collision checks per tick; Frame rate; how many objects you have in your project or on screen; any other issues you are seeing. Also, remove the collision checks to test the root of any issue you are seeing.

From your response, I still can't tell if you have done that or not.

bro why are you trying to convince me that I don't know what I am talking about, what is the purpose of this discussion?

yea that vampire survivor-esque push out solid thing you made is nice!

I guess the build in collision cells must update when an instance moves I assume (well not the whole thing but the specific instance) instead of just every frame. Plus they also handle objects with different sizes.

I'll check the spacial hash out you linked, definitely seems like a custom solution is the best for extreme cases.

Still would be awesome to have access to the build in system and I assume (naively) it shouldn't be much more work for Scirra then to expose the interface.