Legacy GM Fast Collision System?

[Andy]

I have noticed a new feature in GMS called the fast collision system:

Toggling the feature greatly improves my project's performance, however some things start acting strange. Can anyone explain more about the fast collision system? What compatibility issues are there between the new and old system?

I am very interested in this new feature.

 

[Mike]

It's a new spatially based collision system that can make massive speed ups in collision testing.

It's in as an option so users can properly test it, and while it should be working fully, if you have a test case that doesn't, we'd be interested in seeing it. Which version are you on?

 

[jackhigh24]

It's a new spatially based collision system that can make massive speed ups in collision testing.

It's in as an option so users can properly test it, and while it should be working fully, if you have a test case that doesn't, we'd be interested in seeing it. Which version are you on?

so is that similar to using a ds grid based system but without having to use a ds grid based system, as im trying to read up on a spatially based collision system but google is little hard to track down decent info on that.

 

[Mike]

Not quite, it's a tree based system so it's even more optimal than that.

 

[RujiK]

...I just wrote a spatial based collision engine last week... I wonder if this would be faster.

 

[Andy]

It's a new spatially based collision system that can make massive speed ups in collision testing.

It's in as an option so users can properly test it, and while it should be working fully, if you have a test case that doesn't, we'd be interested in seeing it. Which version are you on?

I am working on version: 1.4.1760

If I make a simple program like this:

Spoiler: Code

Information about object: obj_player
Sprite: spr_player
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent:
Children:
Mask:

No Physics Object
Step Event:

execute code:

{
if not (collision_rectangle(mouse_x-100, mouse_y-100, mouse_x+100, mouse_y+100, all, 1, 1))
{
direction = point_direction(x, y, mouse_x, mouse_y);
speed = 3;
}
else
{
speed = 0;
}
}

______________________________________________________

Information about object: obj_block
Sprite: spr_player
Solid: true
Visible: true
Depth: 0
Persistent: false
Parent:
Children:
Mask:

No Physics Object
______________________________________________________

It will only detect collision_rectangle with the old system. GMX of above test: http://www.filedropper.com/testfcsgmx
I figured either it's a bug, or maybe some old functions are not compatible?

Either way I am excited about this new collision system. My thanks go out to everyone at YoYo who helped make this.

 

[Spasman]

It's a new spatially based collision system that can make massive speed ups in collision testing.

It's in as an option so users can properly test it, and while it should be working fully, if you have a test case that doesn't, we'd be interested in seeing it. Which version are you on?

Collision doesn't seem to deactivate on instance_deactivate_object()

 

[TalkyLemon]

It will only detect collision_rectangle with the old system. GMX of above test: http://www.filedropper.com/testfcsgmx
I figured either it's a bug, or maybe some old functions are not compatible?

It's probably a bug, I'll take a look at it - that link isn't working for me though. Any chance you could try uploading it again so I can see it in your project?

Collision doesn't seem to deactivate on instance_deactivate_object()

This sounds like another bug - how were you testing for the collisions? (Collision events or through a collision_() call? I suspect it doesn't matter and it's broken for both but it's good to know before I start testing!)

 

[Andy]

It's probably a bug, I'll take a look at it - that link isn't working for me though. Any chance you could try uploading it again so I can see it in your project?

Thank you for looking into it, here is a new download link: https://www.dropbox.com/s/n9jkeekn1z2140i/test_fcs.gmx.zip?dl=0

 

[Spasman]

This sounds like another bug - how were you testing for the collisions? (Collision events or through a collision_() call? I suspect it doesn't matter and it's broken for both but it's good to know before I start testing!)

I used collision_(). The rest of the object deactivates just fine, it just seems to be the collision box that fails to deactivate.

 

[TalkyLemon]

Okay, thanks guys, I've got those bugs fixed in our internal builds now.

For what it's worth Andy, your issue showed up a problem with passing "all" into several of the collision functions. Once I'd fixed that it also showed up an issue passing in true for "notme".

Spasman, your issue should be sorted too, as you say we had missed some checks for deactivation.

Pete.

 

[Andy]

Okay, thanks guys, I've got those bugs fixed in our internal builds now.

For what it's worth Andy, your issue showed up a problem with passing "all" into several of the collision functions. Once I'd fixed that it also showed up an issue passing in true for "notme".

Spasman, your issue should be sorted too, as you say we had missed some checks for deactivation.

Pete.

Thank you for the update, glad you guys were able to fix the issues!

 

[Spasman]

Radical

 

[Static_Cat]

Physics collision not working.

Hejhej,

I'm pretty new to GameMaker Studio and am currently building a platformer with physics and destructible environment.
The environment consists of pretty small blocks that can be destroyed individually. Because I use physics, every object
that should have collision (as those blocks do), needs a fixture. Pretty soon I discovered, that lots and lots of fixtures cause
performance problems. Using a block-controlling manager that only creates fixtures on the outer edges of block areas
improved that performance immensely, while still maintaining a fully-destructible block environment. But I'm still not satisfied
with the performance and so I discovered the "Use Fast Collision System" option...

Long story short: After enabling "Use Fast Collision System" my player object, which has a fixture, now just falls through
blocks, which have fixtures, too. Does the Fast Collision System not play well together with Box2D physics? Did
I forget something? I could imagine that Box2D has its own collision determination methods, but in that case, why are my
physics collisions influenced at all?

Btw.: collisions that I determine by code (e.g. place_meeting) seem to work fine, though.

 

[TalkyLemon]

Hi Static_Cat!

The fast collision system should be totally separate to Box2D; as you guess, Box2D has its own collision system. I have checked a quick demo locally and have Box2D collisions working with and without the fast collision setting. I would guess this probably means there is something not quite right with how you are setting up your Box2D objects...

(Turning on fast collisions will still speed up calls to the collision_/place_/position_ functions though, so there still is a benefit to turning it on.)

Pete.

 

[Static_Cat]

Hi Pete!

First of all, thanks for the quick reaction.

Now, how DOES one set up Box2D objects correctly? I'm creating fixtures in the Create events of objects like here www.yoyogames.com/blog/70 .
My debug view shows all those fixtures correctly. The player object has a collision event with the block base object, with placeholder code (a comment).

Without the Fast Collision System everything works fine. The player lands on blocks and doesn't fall through. Rockets and grenades explode on impact
(blocks and player).

With Fast Collision System enabled, collision events seem to be completely ignored. The player object falls through blocks, rockets fly through the player
and blocks without exploding (normally a reaction to the rocket <-> block or rocket <-> player collision event). Grenades are just falling through blocks
without going off.

I have the latest version (professional) of GM:S. Switching to beta branch doesn't change anything about the above mentioned behaviour. I have NOT
checked "Uses Physics" on any object. Like I said before, I create fixtures by code. For the sake of this problem, however, I tried checking "Uses Physics"
on the objects in question - didn't change anything.

Plz halp!

 

[Chreech Okash]

WOW "use fast collision system" is actually "use slow collision system". I have made a test by creating two objects and placing collision command inside them. For example one is player object and the other is bullet object. Then i placed the player and 100 bullet objects on the player to test this fast collision system. And i was shocked to see that both in windows yyc and regular you are getting a lot better performance with this "fast collision system" ticked off. After a little more test what i figured out is that "fast collision system" gives better performance only when collision is happening between instances of the same object for example collision between bullets. But when collision takes place between different objects for example collision between player and bullets then this "fast collision system" is a lot worse than "normal collision". Please yoyogames check and fix this issue.

 

[Andrew Armstrong]

Hi Pete!

First of all, thanks for the quick reaction.

Now, how DOES one set up Box2D objects correctly? I'm creating fixtures in the Create events of objects like here www.yoyogames.com/blog/70 .
My debug view shows all those fixtures correctly. The player object has a collision event with the block base object, with placeholder code (a comment).

Without the Fast Collision System everything works fine. The player lands on blocks and doesn't fall through. Rockets and grenades explode on impact
(blocks and player).

With Fast Collision System enabled, collision events seem to be completely ignored. The player object falls through blocks, rockets fly through the player
and blocks without exploding (normally a reaction to the rocket <-> block or rocket <-> player collision event). Grenades are just falling through blocks
without going off.

I have the latest version (professional) of GM:S. Switching to beta branch doesn't change anything about the above mentioned behaviour. I have NOT
checked "Uses Physics" on any object. Like I said before, I create fixtures by code. For the sake of this problem, however, I tried checking "Uses Physics"
on the objects in question - didn't change anything.

Plz halp!

Hey I've just run into this issue too, and I'm not quite sure what to do. All my collisions are suddenly not happening at all. At first there were only a few broken collisions, and now it seems all of them are broken.

Are you perhaps using iOS YYC? I didn't have this problem until trying YYC.

UPDATE: I ended up restarting Gamemaker, clearing the caches and whatnot, and this issue fixed itself. Idk, maaaan.

 

[makas]

Hey I've just run into this issue too, and I'm not quite sure what to do. All my collisions are suddenly not happening at all. At first there were only a few broken collisions, and now it seems all of them are broken.

Are you perhaps using iOS YYC? I didn't have this problem until trying YYC.

UPDATE: I ended up restarting Gamemaker, clearing the caches and whatnot, and this issue fixed itself. Idk, maaaan.

I have the same problem, my setup is almost the same physics objects with "empty" collision event in more of the cases, but there are some code in a lot other, there is not a single collision detected with the fast collision system enabled... I restarted gamemaker and I had no luck though

 

[Dr Greb]

It's a new spatially based collision system that can make massive speed ups in collision testing.

It's in as an option so users can properly test it, and while it should be working fully, if you have a test case that doesn't, we'd be interested in seeing it. Which version are you on?

Actually, Mike I have one.in GMS1 unreg, but I haven't tried in studio2 or any others

https://uheartbeast.itch.io/heartbeast-movement-engine

This is Heartbeasts movement engine, I've been playing with it for a while and found a bug I can trigger 100% of the time.

Here's how:

Start up the gm file, and turn ON fast collisions ( it works with both options checked but there's a HUGE increase in frequency with it on)
go into the map editor and take o_mountain and scale it up to 4.5 x 4.5 and put it in the room somewhere
start up the game and move the o_player back and forth on the o_mountain on the right side, and you will eventually (after about 20-30 seconds of testing) snap over to the far right side of the screen.

What's happening? There's an if while loop happening somewhere in the move_movement_entity script


if (place_meeting(x+hspd, y-yslope, collision_object)) {
// Move to contact and bounce
while (!place_meeting(x+sign(hspd), y, collision_object)) {
x+=sign(hspd);
//break;
}

This is it, but in the version you will download the //break; was left out or forgotten, adding it back, or replacing the while with if seems to make the glitch go away.


The fast collision system check mark makes a really big difference in the bug activating. I don't exactly know what's going on, but that bug drove me crazy for 3 days before I squashed it. I've emailed Heartbeast about the fix aswell.


I hope I'm helping some how

 

[Mike]

You'd have to file it as a bug along with the example so we can examine it properly.

 

[Rukola]

I've found a bug where instance order doesn't matter anymore when fast collision is used.

You can perfectly see it my beautifully crafted example

What basically happens is the fast collision system ignores instance order and interprets it seemingly random!

I'll report it as well, but posting it might just give it some extra urgency ?

 

[RangerX]

Bump!

So what's of this bug?
Was it ever real and fixed?

#Mike

 

[flyingsaucerinvasion]

with fast collision system, using collision_line, the notme argument appears to have no effect.