Hey guys! I checked the forums but didn't see anything about this.

I recently thought about a way of optimizing collisions with static elements (walls, for exemple) but I'm not sure if the benefit would be that great, if other, better ways already exist or if GameMaker is already optimized for collision checks.


My idea is to implement a collision grid.

DESCRIPTION
* Let's say I create a 1000x1000 room and use 32x32 static walls to create the level.

* Upon execution, a 1000x1000 array is created and every walls register their collision bounding box in the array.
** Example: A 2x2 wall placed at (0,0) would flag as true the following adresses: [0,0], [0,1], [1,0] and [1,1].

* After registering itself, the wall is destroyed.

* Instead of using built-in collision checking for walls, I directly check the concerned adresses in the array.
** Example: I need to know if a wall-collision exist a position (2,4). I'll check if address [2,4] in the array.

QUESTIONS
1. Is array checking fast in GM?
2. Is this method better than iterating through every instances of Wall objects?
3. Is this method better than creating a single, large wall object?
4. Is collision_checking in GM already so optimized that I don't need to implement such a system?
5. Do you know other, better ways of optimizing collision checking?
6. Navigation grids already exit in GM, although it exists for path-finding, can I use this framework for collision checking?
6. Ultimately, do you think it is a good idea?


PS: Sorry if my discourse is convoluted, English isn't my primary language

It's a nice idea, but it really depends on your game. If you have more than 300 active wall objects at the same time, then yes, you should go with this system. Otherwise you can just deactivate walls you don't see, and activate them once you do.

1. Array checking is fast in gm... Well, can't say it's fast when you compare GM with other languages, but it's same as checking for a variable twice. This is what I think though, don't take my words here seriously.
2. Of course it is, GM handles a ridiculous loop for every instance you have in the room. The less instances you have, faster the game will run.
3. The system is easy to use, and it's kinda easier to make rooms once you have that system. Since it's kinda tough making one huge solid for every room, loading it's sprite in the game would take much memory, considering your room would be 1000x1000...
4. No, collision checking in GM is slow.
5. Deactivate walls you don't see, and activate them once you see them.
6. That system is pretty much your idea... It can be used for path finding, but I can't see why couldn't you use it for your idea. You can debug it easier too.
6. The idea is fine, and already implemented in many games.

Using GML to optimize Game Maker's built-in functionality is a bit like using a horse to make a car go faster.

In general, GML is slow while the GM collision system is relatively fast. For special cases, maybe a GML solution would be better. For certain kinds of collisions, maybe much better. SAT might be good for physics-based collisions. A BSP or quadtree might be better for certain large applications. Whatever you are trying to achieve for a specific project should dictate any decision to replace the built-in collision system.

If you can achieve speed improvements with instance deactivation and instance reduction, that's where I'd concentrate.

In answer to question 5: Draw all of your walls to a bigger (Let's say 256x256) sprite and then destroy your small 32x32 blocks and you'll have to check agains't a smaller number of 256x256 with precise collision on. That way you're not using a horse to drag the car faster, you're juste removing useless stuff from the car.

Edit: That way, you're still using GM's built-in collision system which is already fast enough for most games.

Well, I guess it depends on what you mean by a collision.

The game maker built-in collision checking works for pixel-perfect collisions between two irregularly shaped objects. I assume it also is efficient in the cases of square bounding boxes (i.e when precise checking is not enabled.)

Because you're talking about walls, which are regularly shaped (at least can conform to a grid), obviously some logical simplification (like you suggested) could occur. But what about the object that is colliding with the walls? Is it also regularly shaped? Can it move pixel-by-pixel or does it only move on the same grid?

Because I think if you have an irregular shaped object, or even just if you want smooth pixel-perfect collisions with the walls, I think the problem isn't really simplified by your method. Like are you going to check every point on the character's (or moving object's) bounding box for collision with your grid? I suspect that the GML built-in collision checking would still do that more efficiently.

Basically, I'm suggesting that grid-based collision testing is only more efficient if the movement is also restricted to grid based, otherwise it is still a full on point-by-point (all points on the bounding boxes of each object need to be tested) collision problem.

But I could be wrong. Really in these "which is faster" type questions the best answer is: test it yourself and benchmark it.