@Ingemar:
And that would be the challenge in this method. And it is cheating in the sense that it is in the physics and advanced math forum and my implementation shamefully uses Prometheus code in areas where I am too lazy to go back into OpenGl (although it could just use gl)...isn't so easy to do on the GPU.
@Phibermon:
Or if you broke up the collision detection into segmens and scanned those for even a single pixel you could use that to get 'pixel perfect' to the nearest group of pixels depending on hardware
And with a velocity variable, you'd be all set to go as to where the collision is from with some simple math from the near centre of the colision pixel group - of course that would use up a lot of cycles but would yield an accurate result.
I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.
Instead of GPU you can also draw the collision test polygons in TCanvas, for example of a TBitmap. You can still draw them on GPU to for the looks but like said, it's propably not fast to read the results from it. And if you draw to GPU they need to be convex.
Overall, unless the polygons consist of hundreds of vertices, the math way will propably be more efficient.
edit: For the math way, if it's ruled that polygon must be convex, then isn't the only scenario such that at least 1 vertex must always be inside other polygon? I recall reading of doing this test with just dot product.
Last edited by User137; 19-08-2011 at 06:15 PM.
Seems to me that because the computer only uses ones and zeros the fastest way to detect a collision would be to filter the polygons with XOR but I'm kind of a newbie on pascal programming, I used to program a bit of assembler on the commodore 64.
Oh, hello everybody.
Bookmarks