GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#1 2010-09-14 11:04:50

BlueMoonProductions
Member
Registered: 2010-08-25
Posts: 22

(simple!) collision_triangle

Hey,

A few days ago I wrote a simple collision_triangle script.

You can download the example(including the scripts) here: http://easy-upload.nl/f/rOYFPBma (gm8) (use mouse to move the object, space to generate random triangle coords)
(EDIT in the collision_triangle script, you can remove the variabele 'i' in var ... ; /EDIT)

This is the syntaxis:

Expandcollision_triangle(x1,y1,x2,y2,x3,y3,obj,prec)

x1 .. y3 are the triangle-coordinates.
obj is the object to check, this is an id, not an index!! It's not hard to rewrite the script to an index-compitable-version.
prec: the same as the build-in collision_ functions.

One important thing, the sprite's origin, must be located on the sprite's bounding box itself, and if the precise-argument is true, on the sprite itself. So:
YSH56R6r
You won't get any errors if you didn't do this, but the script may return the wrong value.

The script uses point_in_triangle (in the GMK you can also find 'is_clockwise', but you don't need that one).
It's not perfect, but way faster than the current collision_triangle. Maybe you could add this one as 'collision_triangle_simple'?

Blue

Last edited by BlueMoonProductions (2010-09-14 11:12:04)

Offline

#2 2010-09-14 14:33:42

xot
Administrator
Registered: 2007-08-18
Posts: 1,240

Re: (simple!) collision_triangle

A faster, simpler alternative might be a good thing to have.

My main concern with this is that it doesn't work like the built-in collision_* functions. I'd prefer it if it accepted all of the same arguments and returned an instance id. This is nearly there. Admittedly, the existing collision_triangle has the same problem. One advantage of your script is that it doesn't require Pro/Registered Game Maker.


Abusing forum power since 1986.

Offline

#3 2010-09-15 02:39:55

BlueMoonProductions
Member
Registered: 2010-08-25
Posts: 22

Re: (simple!) collision_triangle

That's true. I rewrote the script, and it can now handle indices instead of id's, and it has the 'notme'-argument. I haven't tested it yet, but i think it's correct:

Expand/// collision_triangle(x1,y1,x2,y2,x3,y3,obj,prec,notme)

var xx, yy, coll_line;

xx[1] = argument[0]
yy[1] = argument[1]
xx[2] = argument[2]
yy[2] = argument[3]
xx[3] = argument[4]
yy[3] = argument[5]

coll_line[1] = collision_line(xx[1],yy[1],xx[2],yy[2],argument[6],argument[7],argument[8])
if (coll_line[1]!=noone) then return coll_line[1]

coll_line[2] = collision_line(xx[2],yy[2],xx[3],yy[3],argument[6],argument[7],argument[8])
if (coll_line[2]!=noone) then return coll_line[2]

coll_line[3] = collision_line(xx[3],yy[3],xx[1],yy[1],argument[6],argument[7],argument[8])
if (coll_line[3]!=noone) then return coll_line[3]

with (argument[6])
 {
  if (point_in_triangle(xx[1],yy[1],xx[2],yy[2],xx[3],yy[3],x,y) && argument[8]!=id)
   return id
 }break

return noone

Oh, and does anyone have an idea how to fix the origin-should-be-on-sprite bug? sad

Last edited by BlueMoonProductions (2010-09-15 02:42:14)

Offline

#4 2010-09-15 04:46:58

xot
Administrator
Registered: 2007-08-18
Posts: 1,240

Re: (simple!) collision_triangle

It's more like a limitation than a bug, isn't it? I don't think there is a simple, fool-proof solution.

This problem was examined pretty thoroughly in this old GMC topic:
http://gmc.yoyogames.com/index.php?showtopic=106307


Abusing forum power since 1986.

Offline

#5 2010-09-15 04:51:56

BlueMoonProductions
Member
Registered: 2010-08-25
Posts: 22

Re: (simple!) collision_triangle

Call it limitation, whatever: it is a (small) problem..

I browsed through the topic, but I couldn't find any solutions(right?)..

Offline

#6 2010-09-15 04:59:49

xot
Administrator
Registered: 2007-08-18
Posts: 1,240

Re: (simple!) collision_triangle

I'm naturally biased toward my own sprite-based solution, which in fact was developed in that topic. Before that script I came up with a promising scan-line solution, but it was capable of false negatives because of low resolution scanning (which is really the only practical way to use it).

As I recall, all the rest had the same problem when the origin was not within the bounds of the sprite image. As long as that problem can't be addressed, I prefer just going with the simplest overall method like you have; side-collisions and a point-in-triangle test.


Abusing forum power since 1986.

Offline

Board footer

Powered by FluxBB