If the object is small, I think this is a good solution.
It is a solution, but I think it would be a fairly expensive one compared to a pure maths solution (I did find one, and have included an example below)
I don't think it's just the cost of checking for the collision (position_meeting, doing point_in_rectangle is a simple comparison of less than / more than) but the fact you need two for loops to do it as well.
I come up with an idea of using tangent line to simulate ellipse.
First tangent line, then split the shape to triangles.
I'm not sure if this idea is easy to accomplish. Just an idea I want to share with you.
I don't know about tangent line, so it's really a question of whether you know the maths / thinking behind it. If you are able to figure through it, then a repeat loop and point_in_rectangle would probably cost less. It depends on how much maths you actually have to do to get these points:
You've got 7 points there to check, and it's somewhat more refined when it comes to cutting out the extra space when "redefining" the original shape.
Depends on:
1) If you know how to figure out these points
2) Just how much computation is required to do so
3) Whether it's still too imprecise to be accurate. In your example there's still two areas where it results in modest amounts of empty space (furthest left circle, furthest right circle)
You can figure out the arc of the ellipse (I'm cheating a little by knowing some dimensions here, as this is using a sprite of an ellipse for a visual comparison):
Code:
width = sprite_width / 2;
height = sprite_height / 2;
theta = 90; // angle that will be decreased each loop
while (theta >= 0)
{
converted = degtorad(theta)
xx = x + width * cos(converted)
yy = y + height * sin(converted)
draw_line (x,y, xx, yy)
theta -= 1;
}
In the above code it will draw around the shape of the ellipse I have as a sprite. Though for reasons that are beyond me it is being calculated upside down. Here is an image:
The green is the background of the room, so as to make it more visible. The blue / red is the original drawn sprite. The black lines are the drawn lines from the center to the calculated point.
As you can see, it is very accurate...albeit the "wrong way around". However, you can easily fix that, or work around it.
Taking the above WHILE loop: Now you know the point on the arc, if you duplicate this point three more times by reversing the xx / yy positions, you have four points around 360.
Then you check those four points for point_in_rectangle (or whatever object)
At a rough guess that would be less costly than any other type of check, due to using less loops (one loop , and is short in repeat number) and not needing pixel checking (or however it is that collision checking is done)
If the ellipse is angled then you'd have to account for that somewhere in the above code. Which, admittedly, I haven't yet considered how to do and am unsure if the calculation changes depending on the ellipses orientation
(I nicked it from an online maths tutorial - they are quite useful for finding the equations involved)
EDIT: I really, really, really (really!) can't figure out how to use this for angled ones.
Code:
is_end = 90;
theta = 90;
repeat (is_end)
{
converted = degtorad(theta)
xx = x + width * cos(converted)
yy = y + height * sin(converted)
dist = point_distance(x, y, xx, yy) // xx and yy are the wrong way around to begin with (as above)
angle = point_direction(x, y, xx, yy) // xx and yy are the wrong way around to begin with (as above)
xx = x + lengthdir_x(dist, angle + image_angle + 360); // 180 works too, though its always the wrong way around whichever I use
yy = y + lengthdir_y(dist, angle + image_angle + 360);
draw_line (x,y, xx, yy)
theta -= 1;
}
You can see it is matching an angled ellipse, but I don't understand converting the end result. This is a fudged outcome....it works, but I'd prefer knowing why
