Collision detection for 2d/planar textured polys

Newbie & Debugging Questions
#1

Hi. I use Jogl to draw some 2d “sprites” (like explained in Kev’s nice Space-Invaders tutorial): a sprite consists of a planar quad polygon with z=0, texture mapped. Usually a texture has got an alpha layer, so it can be blended with an 8bpp mask on the background (RGBA texture).

When it comes to collision detection I could probably use some bounding boxes in the form of circles or ellipses. However in the good old home computer days, there’s been some sprite chips which allowed detection of pixel wise collision.
Would pixel collision detection work with alpha textured quad polygons in Jogl (or OpenGL), too? Right now I couldn’t imagine how this could work, but maybe you smart guys out there know more.

PS: Sprites will need to rotate around the z-axis, too.

#2

Just throwing this around in my head and wondered if you could something like rendering in select mode.

  • Render everything that you might collide with one name and with the stencil buffer set to write
  • Render the collision target with a second name with the stencil buffer setup only to draw where it was previously written
  • Check the GLSelect response for drawing of the collision target.

I’m not sure if GLSelect counts a poly as rendered if it wasn’t actually written due to a stencil filtering. I’m also not sure if this would be quick.

Also, I’m pretty sure you’d want to do a bounding box check first.

Kev

#3

Someone from round these parts (zparticle?) had a bitmask collision testing routine that was pretty damn fast. Basically AND’ing some pre-created boolean arrays together at the correct offsets. Not sure how you’d cope with rotations, but I suppose you could also pregenerate those as well if you wanted.

Should be in the forum archives somewhere…

#4

Search for a software rotation tutorial (256 colors “mode x” would be a good starting point). Take the alpha channel and rotate it that way. Then you can check against those rotated alpha pixels (>127).

However, it’s rather slow - therefore precheck with bounding boxes. Oh and pixel accurate collision detection is overrated :wink:

#5

Thanks people for the ideas.
If possible, I’d prefer Kev’s idea of hardware (stencil) testing. However it’s yet unclear if it works. :slight_smile:
Software detection seems slow to me: I intend to have lots of sprites on the screen, and many of them will be rotated at any angle all the time.

Bounding rects will of course be used as pre-selection. However, if bounding rects / circles only will do, I can’t judge yet. A friend of mine says it must be pixel accurate, and well, we both played Xenon (II) in the old days and damned the inaccurate collision detection. :wink:

#6

I’m only blathering, so if someone with lots of OpenGL knowledge could chime in I’d appreciate it…

I’ll try and rough something up if I get a chance, to see if it works

Kev

#7

Thinking about it, I’m not sure you’d be able to tell what you’d hit.

Kev

#8

Oeer, change my mind again. If you stencil in the target of the collision (say the spaceship) then draw all the targets in the area against that alpha stencil they only draw if their intersect the orignal sprite.

The GL_SELECT might then return the list of hits as only the things that have intersected with the target…

That might even work,

Kev

#9

Bad news, seems GL_SELECT ignores stencilling. So it don’t work, sorry.

Kev

#10

Software detection seems slow to me

It’s faster than it looks like. Keep in mind that you don’t draw that rotated thingy. So no ram -> vram delay.

However it’s ofcorse slower than hitboxes. Btw don’t forget that you can also just use hitboxes wich are a bit smaller than the sprites (own hitbox smaller/enemy hitbox bounding - in favor of the player).

Also those (vs alpha) checks can be optimised in several ways. Eg scanline-ish. But, as I already pointed out, it’s slow and overrated. Really. Even the newest games doesn’t use per pixel col. Just use in favor of the player collision detection and everything is ok :wink: