• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - Code Is GM's built in collision code optimized?

Hi! I've been working on my platforming game for about 3 years. There's a lot of object interaction, such as being able grab and throw objects, attach them to other objects, attach strings or rods to objects, glue them to the terrain. It's fairly robust. It's all using verlet integration and different kinds of constraints.

So I've created my own physics engine for it. I have my own collision system that handles many different types of shapes (using SAT for polygonal shapes) and sorts the objects in a hash table. It's fairly optimized to handle the number of objects I'm using.
I just want to know if this is all worth it. Does the built-in collision system use any kind of quadtree or spacial partitioning? Is there any reason the built in functions would be faster, or should I continue to use my own system that is specially designed to work for my game?

I've always been against using pre-made code and stuff, but I just would like to know if the collision is especially optimized behind the scenes. If so, I should be able to make a kind of hybrid of the two.
The latest iteration of collision uses a quadtree system if I or something very similar. It is very fast and allows for calling collision checks sometimes in the 100,000's per frame (depending on whether or not there is actually a collision). I would recommend using the built in system unless it doesn't offer something your game specifically requires.

GMS 1.99.x and GMS 2 have the newest collisions implemented.


It uses an R-tree and seems to work best with many static objects rather than many moving objects.

Stable builds of GMS1.4 have this feature, called "Fast Collision System", under the General tab in Global Game Settings. We use FCS for HLD and consider it stable enough for production builds, though whether it meets OP's needs is a separate question.

"It is optimised" is too broad of a question to answer as one can optimise for many different things - optimising for memory footprint, optimising for AABB collisions, optimising for accuracy/determinism etc. For a useful answer, it helps to be as specific as possible.
The built in physics we are talking about are the box2D or the "place_meeting" stuff? Because the OP used the expression "polygonal shapes" and last time I checked the only box2D allowed polygonal shapes for collision... the builtin uses pixels (am I wrong?!)


Remember, that precise collision checking kills everything, so review your sprites to use square ones where possible (except you really need something else). This will be a huge speed improvement.
Remember, that precise collision checking kills everything, so review your sprites to use square ones where possible (except you really need something else). This will be a huge speed improvement.

Yeahh I know! but I just wanted to know what "builtin" physics we were talking about!! Box2D or the other :)
I'm not actually talking about the physics collision. So not the box2d physics. I just mean the collision checking scripts and stuff like that. I'm handling collision responses my own way.

I mainly need it to be optimized for speed. The game will have a lot of moving objects at any time, but I plan on using some kind of resting system for when they're far enough out of view. Everything is running under the same collision system, like collecting coins/other pickups, hitting enemies with bullets, bumping in to enemies, grabbing objects/enemies. I guess I could just try both of them and profile them.

My game is kind of like spelunky in terms of physics, but a little more complex. For example, you can stand on chests, so if you wanted... you can like attach a string from the ceiling to the chest, and stand on the swinging chest.