Game Development Community

T2D but no pixel perfect collision??

by Marc Dreamora Schaerer · in Torque Game Builder · 03/11/2005 (11:51 am) · 2 replies

I've read the features several times. But the core thing I am missing ( or did I just overread it ) is pixel perfect collision.

Are there plans to add it, as it is a core part of 2D?

#1
03/12/2005 (1:10 pm)
Marc,

Good question. T2D features polygon-perfect collision... actually swept-polygon perfect collision, which means your collisions can't be missed due to "tunelling" when objects are moving very fast. T2D has the most advanced collision detection system I've seen in a 2D engine yet!

We do plan to add more to this collision system as well, but right now, no, pixel-perfect collision isn't supported. We did define the collision interface though such that it is easy to add new types of collision. For example, you could easily add swept-ellipsoid collision. Adding pixel-perfect collision would be a fairly simple matter as well, as you have all the engine's C++ source code, and T2D's code makes it clear where you'd want to add in new collision types.

I'd note as well that you can have polygons of arbitrary complexity for your collision, meaning that you can get results which are nearly as accurate as pixel-perfect collision.

I won't say for sure whether we plan to add pixel-perfect collision, but it would be cool. In the short term, this is the kind of thing that'd be neat to see the community of T2D developers contribute back, and then we may incorporate that into the engine itself, or do an official implementation later. Right now though, or focus is on creating more tools and editors, more documentation, and focusing on some larger technical features.
#2
03/12/2005 (1:41 pm)
Pixel perfect collision really isn't needed. Gasp! Yes, I know, but you've got to remember, we're reading with 3D hardware here. Once you send the pixels to the OpenGL hardware to render, they're off to magic 3D land and you can't get to them easily. Yeah, there are ways to read in data from the framebuffer after polys have been rasterized, but it's slow. Think of it as "fire and forget" sprite rendering.

Now, you could always implement a CPU-based ppcol system, using the original sprites -- But what about rotating? Scaling? You'd have to modify your ppcol routines to take that into account. Worse, now you're sending graphics data to the GPU *and* keeping it around in system memory.

Collision polygons make a more sense in this regard. Since you have any number of points in it, you can make it as complex (or simple) as needed. The shape just has to be convex (no holes or dents). Off the top of my head, I can't think of any shape that couldn't be represented well enough for collision detection with colpolys.