Collision Line vs Collision object performance++

M

MarkyzZz

Guest
Hi. Not quite sure if this question has been already asked, but i would like to know:
Which is the best way to use collision with ground, in order to have the best performance? Using many collision lines, or many stretched invisible objects? Or is there a better way to win performance?
 

TheouAegis

Member
collision_line is one of the slowest collision functions in the game. And if you're considering resorting to invisible objects, you may as well study up on tile collision maps so you don't waste time on flooding all your rooms with objects.
 
T

TimothyAllen

Guest
Ive never experience collision_line being slow. Its faster than place_meeting and instance_place from my experience. If i recal, it also faster to call collision_line over 3 instance_position calls. But who knows, cant say I have any real data.
 
M

MarkyzZz

Guest
collision_line is one of the slowest collision functions in the game. And if you're considering resorting to invisible objects, you may as well study up on tile collision maps so you don't waste time on flooding all your rooms with objects.
So, tile collision is faster than collision_line or collision_rectangle? I thought tiles are static images and you can't use them for collision. I don't really have much experience with GameMaker, but where can i find a good tutorial on how to collide with Tiles? Plus, what if i have slopes? How do you create collisions with slopes using tiles? Is it the same way as with objects?
 
B

bojack29

Guest
I think when they say tile collisions that they may be eluding to grid collisions. They are largely the same thing.
 

RangerX

Member
I am however curious to know which "collision_line" would be slower than "collision_rectangle". I mean, collision like will probably check at the position of each pixel from the defined line and cycle through the instances of the object specified and compare with their mask's pixel positions right? So if it works that way, "collision_rectangle" would probably check for all pixel inside the rectangle and do the same thing --- therefore being slower since it does check more pixels most of the time.
 

Freddy Jones

Your Main Detective
Just use what you're good with and if it gets slow you're probably not using it effectively - meaning it's probably easy to optimize. I've never had a problem with Game Maker's Collison system and objects being slow. In fact, I've tried doing a grid based collision system but my original system using the regular Collison functions were faster. I even had the grid segmented into specific areas to split lookup time but eh. It was absurdly huge, I just figured out more tricks to gm's system I guess.
 

TheouAegis

Member
collision_rectangle just compares 4 values, not a range of values. collision_line may be streamlined to work arithmetically, but it seems to calculate tje slope of the line first. collision_line is slow in all cases.
 

RangerX

Member
collision_rectangle just compares 4 values, not a range of values. collision_line may be streamlined to work arithmetically, but it seems to calculate tje slope of the line first. collision_line is slow in all cases.
Yeah makes sense. I didn't saw it that way
 
B

bojack29

Guest
Wouldnt collision_line basically test in increments of the smaller side of the bounding box of whatever object that it is trying to detect?

So the object in question is thinner than taller in terms of bounding box, so the collision line would use the thinner measurement for testing.

But then you have two trig functions necessary for each incremental x and y check. So I guess it would be quite a bit slower.
 
Last edited by a moderator:
B

bojack29

Guest
So basically the collision_line script simplified looks like this:
Code:
var a, d, o, x0, y0, x1, y1;

//Start
x0 = argument0;
y0 = argument1;

//End
x1 = argument2;
y1 = argument3;

//Direction from point A to point B
a = point_direction(x0, y0, x1, y1);

//Object
o = argument4;

//Distance increment
d = min(o.bbox_right - o.bbox_left, o.bbox_bottom - o.bbox_top);

//Iterate for a collision
while(x0 <> x1 || y0 <> y1){
     with(o){
          if (position_meeting(x0, y0, id)){
               return id;
          }
     }
     x0 += dcos(a) * min(abs(x1 - x0), d);
     y0 += -dsin(a) * min(abs(y1 - y0), d);
}
return -1;
 
Last edited by a moderator:

TheouAegis

Member
As opposed to collision_rectangle, which looks like this:
Code:
with argument4
if argument0 <= bbox_right
&& argument1 <= bbox_bottom
&& argument2 >= bbox_left
&& argument3 >= bbox_top
    return id;
So much faster.
 
T

TimothyAllen

Guest
Every test I've done, indicates to me that collision_line is far from slow and is actually one of the better performing functions.
 
M

MarkyzZz

Guest
And that's when the profiler comes in:
http://docs.yoyogames.com/source/dadiospice/001_advanced use/profiling.html
I can't understand why the profiler is so under-used inspite of the fact that it allows you to see how much time a function takes to get executed; or everything performance, execution time and speed related in general.
Sorry, my bad. I've skipped the debugging chapter. It seems like it's really a good tool and every programmer must know how to use it.
 

TheouAegis

Member
Well now I have to go search for the test I did last time that made me say collision_line is slow. (Update: I should post my test codes, because I only posted my results and I can't even replicate those results. I mean, i get the same speed for collision_rectangle, but I couldn't get the collision_line results I got last time no matter what code I used. So I dunno.)

But then again, in terms of speed vs. effectiveness, even though collision_line is equivalent to collision_rectangle (which is actually pretty damn fast), the two functions are completely different. It takes up to min(x2-x1,y2-y1) collision_line checks to do what one collision_rectangle can do, but a collision_rectangle can't do what a single collision_line can do better.
 
Last edited:
M

MarkyzZz

Guest
Well now I have to go search for the test I did last time that made me say collision_line is slow. (Update: I should post my test codes, because I only posted my results and I can't even replicate those results. I mean, i get the same speed for collision_rectangle, but I couldn't get the collision_line results I got last time no matter what code I used. So I dunno.)

But then again, in terms of speed vs. effectiveness, even though collision_line is equivalent to collision_rectangle (which is actually pretty damn fast), the two functions are completely different. It takes up to min(x2-x1,y2-y1) collision_line checks to do what one collision_rectangle can do, but a collision_rectangle can't do what a single collision_line can do better.
I've used around 3 or 4 collision lines in one of my testing project. I don't know what will be if i check for 1000 collision lines, so dunno exactly which one is better. Will definetely try with rectangles too, if i get to have performance issues.
 
Top