🚀 go-pugleaf

prim!dave@germany.eu.net (Dave Griffiths) writes:

> I am writing a Pinball game which has a TIFF file background onto
> which objects such as flippers, balls, bumpers and lights are
> composited.
> I need to do "hit detection" to determine when the ball has hit <...>

Your basic idea is sound, but I think your proposed architecture is wrong.
(Assuming I understood you correctly.)  Remember that the Window Server
(which will composite the bits between images and put them on screen)
is a separate process from your application.  The bitmaps ultimately
reside in the window server's address space and you can't directly read
data from there.  You can use PostScript to send you the data back, but
that's a rather expensive proposition that you don't really want to
do while you're doing animation.  (An interesting tidbit: the tiff files
are originally interpreted in your address space (by library routines) to
create the bitmaps that are shipped off to the window server.)

I think what you want to do is create a collision array in your own
address space, where the collision array closely resembles the bitmap
of the pinball background.  This collison array could be thought to
resemble a Z-buffer for 3D graphics (if that helps).  Because you 
separate collision areas from appearance, you're free to fancy up the  
appearance.

The approach I describe above (collision table) works well for irregularly  
shaped bitmaps; you compare some interesting points (maybe every pixel) against  
the table; if you get a hit presumably the table describes the characteristics  
of the thing you hit.

Another approach is algorithmic.  This is easy for rectangular regions,
simple polygons or other simple shapes, but harder for more complex shapes.
Fortunately, you can often reduce complex displayed shapes to simple regions
for the purpose of quick and dirty collision detection (reducing circles to  
squares or eight points, for example)  This technique also scales well to
3 dimensional collision detection.

There's a drawback to both of the above; they only tell you about a collision  
after it has happened.  It maybe be difficult to tell how one shape entered  
another, and how to "back-off" to the point at which the collision actually  
occurred.  Worse yet, things may go through each other without ever stopping at  
a point where you detect a collision; you must carefully optimize maximum  
single iteration distances to guarantee that detectable collisions will always  
occur.

Another approach is to calculate when and where the next collision will occur.   
Then an animation step is the normal animation time or the time to take you to  
the next collision time, whichever is less.  Because you have precalculated  
when all collisions will occur, you don't have to look for collisions on every  
iteration, only when parameters change.  Furthermore, you never iterate past  
the point of collision, only to the point where it begins to happen.  This  
technique is difficult if you have objects that have varying trajectories or  
speeds.  However, it can be effectively combined with the other techniques.

As always, I hope this makes some sense and is at least slightly helpful...

-sam

--
Opinions are not those of my employer.  They're not even mine.  They're
probably wrong besides.  How did they get in here, anyway?