We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › 2D "Sprite" Collision detection
Page Index Toggle Pages: 1
2D "Sprite" Collision detection (Read 655 times)
2D "Sprite" Collision detection
Oct 23rd, 2007, 3:15pm
 
Is there any support in the language, or in a popular library, for doing 2D Sprites w/ collision detection? Ideally something you could toss an animated GIF into...
Re: 2D "Sprite" Collision detection
Reply #1 - Oct 23rd, 2007, 4:05pm
 
I've not tried it, but http://pgl2d.bravehost.com/ might help.

However you may have to create a seperate image for each frame of animation.
Re: 2D "Sprite" Collision detection
Reply #2 - Nov 23rd, 2007, 7:54pm
 
I took a look at that library. It seems to... well, do both too much and too little for my needs... too much assumption about the game world I want to make, too little pixel-ish collision detection. It was a kind of nifty idea though.

My primary goal was to give myself an option beyond "bounding rectangles" for collisions in games that I made in processing... kind of hearkening back to the days of 8bit programming, with physical hardware sprites.  I figure the processing equivalent of that is checking the "alpha" channel for the two image's pixels[], and if it was above a certain threshold (128) for both, that's an overlap.

In making this I discovered a "new" (not necessarily more efficient) fact about bounding rectangles... previously I had realized that the easiest thing to do is treat a 2D overlap as two 1D overlaps, checking for horizontal and vertical overlap separately. Then I realized if you sort the 4 endpoint values 2 such line segments have, the only way there's an overlap is if the least 2 of the 4 come from different objects. (This is probably geometry 101, but its been a while ;-)  So I made a comparable object that holds the value and a reference to which object it came from, and rely on Arrays.sort() (there are some edge cases when the overlap is one pixel, but I'm saying close enough for government work) Then I go through the overlap area (I'm still worried there's an off by 1 error lurking in there) pixel by pixel and do the alpha value comparison.

I came up with the following code (still pretty rough) - if you actually want to try it, the sprites I reference are available at http://kisrael.com/journal.aux/lam.gif  and http://kisrael.com/journal.aux/lin.gif
And I call them "sprats" in an attempt to be cute and to avoid namespace collisions.

Damn, the forum says the msg is too long. Src at
http://kisrael.com/journal.aux/2007.11.23.sprat1.txt

Is this worth running with? Beyond my own personal use? I mostly make games for this one site http://glorioustrainwrecks.com -- I will probably make add a very small, ignorable physics model to these, and make it so every sprat has the option of just doing bounding box collisions, since those should be a lot cheaper.
Page Index Toggle Pages: 1