I’m trying to write a small game which consists of using a single bitmap object
that represents a player. They can turn/rotate it as they want, and then head
in the direction they are then pointing at. They can also shoot in the
direction they are pointed
Here is my problem. I need to do collision detection on a bitmap that has been
rotated to see if they are hit by the missile of another player. I’m using
OpenGL to do the rotating. And I’m drawing it in ortho mode, so it is still 2D.
My first idea was to keep the original SDL_Surface, and then move the point I’m
checking to simulate the SDL_Surface being rotated. I cannot seem to get an
algorithim to do this.
The second idea was to kill off OpenGL and use SDL_gfx to do the rotating. That
cut the fps down too low, but at least I can do the checking I was wanting to do.
By third option is to keep OpenGL, use SDL_gfx to rotate on demand for collision
detection. I don’t like that idea, but it might work alright.
Here is my problem. I need to do collision detection on a bitmap that has
been rotated to see if they are hit by the missile of another player. I’m
using OpenGL to do the rotating. And I’m drawing it in ortho mode, so it
is still 2D.
(…)
Does anyone have any advice on how to solve this?
One idea, of which I don’t know how well it would work, is to off-screen blit
the shot and the ship if the if they are near to each other and then check if
the shot is hidden by the ship or not.
Do you actually need pixel perfect collision? The simplest solution
would be to make rough bounding shapes and test those. Spheres are
easy as they are unaffected by rotation, with rectangles or polygons
being available with a little bit more work.
You may find - particularly if you have many objects rotating at once
that SDL_gfx will not meet your needs. Consider especially the low
end hardware you want to support.
HTH,
Brian.On Tue, Oct 21, 2008 at 2:18 PM, Micah Brening <micah.brening at gmail.com> wrote:
Do you actually need pixel perfect collision? The simplest solution
would be to make rough bounding shapes and test those. Spheres are
easy as they are unaffected by rotation, with rectangles or polygons
being available with a little bit more work.
You may find - particularly if you have many objects rotating at once
that SDL_gfx will not meet your needs. Consider especially the low
end hardware you want to support.
HTH,
Brian.
Does anyone have any advice on how to solve this?
Thanks for the reply,
I had considered this. I don’t have to have pixel perfect collision. Plus if
you make things fast pace enough, no one would really be able to notice, right?
The only problem I can see with this is very very simple. I don’t know how to
do it. I understand checking if it is in the rectangle, but that is affected by
rotation if it is no a square, and technically it is even then.
Are there any tutorials out there for this kind of collision detection that
people prefer to use? Or can someone post a C or pseudo example?
Thanks again for the help.> On Tue, Oct 21, 2008 at 2:18 PM, Micah Brening <micah.brening gmail.com> wrote:
I second that. Pixel-perfect collisions are not usually worth the hassle. I get along fine using bounding circles (just check the sum of the radii against the separation distance and use a rigid body collision response: email me if you want specifics). If you’re just asking how to rotate a point, then take a Google for “rotation matrix”. In 2d, I think it’s:
newX = oldXcos(angle) - oldYsin(angle);
newY = oldXsin(angle) + oldYsin(angle);
(angle in radians)
Double-check me on that.
I use Sprig for rotations (in software, like SDL_gfx). On a several year-old computer, I can keep a decent framerate with ~15 dynamically rotated 40x40 sprites on-screen.
Jonny D> Date: Tue, 21 Oct 2008 14:25:05 +0100
From: brian.ripoff at gmail.com
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL+OpenGL Ratation And Collision Detection
Hi
Do you actually need pixel perfect collision? The simplest solution
would be to make rough bounding shapes and test those. Spheres are
easy as they are unaffected by rotation, with rectangles or polygons
being available with a little bit more work.
You may find - particularly if you have many objects rotating at once
that SDL_gfx will not meet your needs. Consider especially the low
end hardware you want to support.
HTH,
Brian.
On Tue, Oct 21, 2008 at 2:18 PM, Micah Brening <micah.brening at gmail.com> wrote:
I would only use bounding circles if you have to (i.e., you have
circular objects), finding the separation distance between two centers
requires a square-root. distance(P1, P2) = sqrt( (x1-x2)^2 + (y1-y2)^2
).
If you have points and rects, just check for inclusion of Point p in
"this" rectangle with bottom left at X, Y, Width and Height
one way to speed this section up (marginally) is to check the
condition most likely to short-circuit first.
hope that helps,
JohnOn Tue, Oct 21, 2008 at 9:59 AM, Jonathan Dearborn wrote:
I second that. Pixel-perfect collisions are not usually worth the hassle.
I get along fine using bounding circles (just check the sum of the radii
against the separation distance and use a rigid body collision response:
email me if you want specifics).
Hi!Am Dienstag 21 Oktober 2008 schrieb John Magnotti:
I would only use bounding circles if you have to (i.e., you have
circular objects), finding the separation distance between two centers
requires a square-root. distance(P1, P2) = sqrt( (x1-x2)^2 + (y1-y2)^2
).
No, you don’t have to, as disctance^2 will work for the comparison just as
well. Now, depending on your hardware the multiplication might be more
expensive than the comparisons …
Regards,
Matthias
Matthias Bach
?Der einzige Weg, die Grenzen des M?glichen zu finden, ist ein klein wenig
?ber diese hinaus in das Unm?gliche vorzusto?en.? - Arthur C. Clarke
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20081021/64d2e1b4/attachment.pgp
one way to speed this section up (marginally) is to check the
condition most likely to short-circuit first.
hope that helps,
John
That is what I had been doing, though I used that as a first pass, and then
would do the pixel perfect calculation if that proved true. But then the
problems I can see with both bounding circles and this method as well is that
say I have a rectangle with dimensions of 128x64, would I be in correct as to
think that if I have this image rotated in a 90 degree or 270 degree that the
checks would come out wrong as this would make the image seem 64x128.
As for the bounding circles, if I use a radius, it would have to be for a circle
that circles the whole image, correct? So the radius would have to be 64, as
the longest diameter is 128, which would them cover an extra 32 both above and
below. Not much, but on a shooter, those few pixels can mean game over.
That is what I had been doing, though I used that as a first pass, and then
would do the pixel perfect calculation if that proved true. But then the
problems I can see with both bounding circles and this method as well is that
say I have a rectangle with dimensions of 128x64, would I be in correct as to
think that if I have this image rotated in a 90 degree or 270 degree that the
checks would come out wrong as this would make the image seem 64x128.
I was only suggesting to use that method once you had applied the
appropriate transform to the points. As Jonny D mentioned, you should
be able to transform the “bullet” in the same way you transform the
target, then do the collision detection.
Not much, but on a shooter, those few pixels can mean game over.
As long as the animation is smooth and the frame rate is high, people
won’t notice a few pixels. What they will notice is if the animation
grinds to halt as you go from the first pass collision detection to
doing the pixel perfect calculation. Nothing beats a benchmark though.
I was only suggesting to use that method once you had applied the
appropriate transform to the points. As Jonny D mentioned, you should
be able to transform the “bullet” in the same way you transform the
target, then do the collision detection.
Sorry, I misunderstood. It seems to me that this would be a more advantageous
route. While pixel perfect isn’t really required, I’m thinking that that
calculation of quickly(?) rotating the point would be more optimized than to
generate bounding circles.
However, if it is to do with a ship collision, or something other than a single
point, then yes, bounding circle sounds like the way to go. So in all honesty,
I would like to implement both for their own purpose.
Though for me, the pixel perfect calculation consists of a single getpixel call.
Again, that is for a single point. If it were an object other than a
missile/laser, I would want something more than several calls to getpixel.
Not much, but on a shooter, those few pixels can mean game over.
As long as the animation is smooth and the frame rate is high, people
won’t notice a few pixels. What they will notice is if the animation
grinds to halt as you go from the first pass collision detection to
doing the pixel perfect calculation. Nothing beats a benchmark though.
Sorry if my responses have been incorrect, if not arrogant. It’s the problem
with some self taught programmers, think we learned it the hard way also means
we learned it the right way.