Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: jamin1@psu.edu (Jamin Frederick) Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: pixels Date: Fri, 11 Jul 1997 02:34:44 GMT Organization: SCEA Net Yaroze News Lines: 87 Message-ID: <33c595c2.31159264@news.scea.sony.com> References: <33c122d9.168381829@news.scea.sony.com> <33c3d7f6.4808700@news.scea.sony.com> <33C48A1C.3895@bc.sympatico.ca> NNTP-Posting-Host: nbppp42.cac.psu.edu X-Newsreader: Forte Free Agent 1.11/32.235 >I've used gobs of weird hacks for collision detection in games, and I've >always been able to find a way around pixel-by-pixel. I thought I'd >list some of them off: > Thanks for the tips! The only problem is that my sprites have already been drawn, and I think it may look silly to use just bounding boxes (they're tanks, and so don't move real fast -- bounding boxes would be really noticable, even if I rotated rectangles). However, if I only use the main memory and don't do any StoreImage()'s I think it can still be quite speedy. The intersection-bounding-boxes rectangle (once the bounding boxes have collided, of course) of sprites doesn't usually get that large if the sprites are to stop (or destroy) upon collision, perhaps 10 x 10 pixels at most. But for my game, the tanks are only moving about 2 or 3 pixels a second at most, so the overlap of a building or something would only become about 3 x 3 pixels at most. For a tank against a tank maybe 6 x 6 or so. But 10-30 pixels of comparison isn't bad (and that's only when there IS a collision). I've trimmed down the logic for the calculation of the secondary intersect boxes for each sprite (for pixel-by-pixel comparison), using MAX and MIN. I'll give it a try, and if it's too slow, I guess I'll have to try an alternative! >0. Make your game so intense no one has time to notice that collisions >are pixel exact or not. > >1. Simple shapes as hit regions - design the art so it fits well into >shapes that are easy to mathematically check against, like rectangles, >circles, and triangles. > Another addition to #1 is to reduce the bounding box so that it represents the "bulk" of the object. >2. Rotated simple shapes as hit regions - sometimes you've got objects >that can rotate - rotating a rectangle and checking it against another >rotated rectangle is still cheaper than pixel-by-pixel. > >3. Stick Figures. Say you've got a figure like a character in a 2d >fighter. Make a simple stick figure that mimics the shape and motion of >the sprite, ie: a line for the head, a line for upper arm, lower arm, >hand, two lines for the torso, etc. etc. Then to do hit detect with the >other character in the game all you have to do is treat each line as a >fat line and check them against the fat lines in the other character. >This has the advantage of letting you know that the hand connected with >the noggin. > >4. Simple hierarchical shapes. Say you've got a top down view of the >TOS U.S.S. Enterprise on the screen. Do your hit detecting on a circle >and three rectangles, one for the two engines and one for the >engineering hull, with the rectangles of course rotated according to the >orientation of the ship on the screen. > >5. Polygon shapes. Make a polygon outline that fits around the shape as >tightly as you'd like so that game feels good, then check for >intersection with collidable objects. If you design it right you can >have one complicated polygon collision shape which you test against some >trivial shape like a rectangle, but even still, poly-poly intersection >is faster than pixel-by-pixel, unless your sprites are really tiny, in >which case suggestion number 1. is probably the best IMO. > When using shapes, are you talking about calculations involving the ideal shapes, using real geometry, as opposed to "aliased" calculations? >Hope this helps, or gives you some ideas, > Thanks. You know, its too bad I've never seen a book concerning detailed video game techniques such as this. Most of the books I've seen only vaguely cover such topics...they don't get into issues like how often to do updates (every frame or every couple of frames?) or when not to do certain logic so that you have maximal frame rate, etc. I guess maybe it all depends on the speed of your hardware. Has anyone seen any [somewhat involved] 2-d games for the yaroze to give us some hints? Most of the stuff I've seen so far has been just space invaders fare, nothing too dynamic... Jamin