Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Code Snippets / [DBP] Pixel Perfect Sprite Collision

Author
Message
Kira Vakaan
15
Years of Service
User Offline
Joined: 1st Dec 2008
Location: MI, United States
Posted: 24th Feb 2009 01:29 Edited at: 24th Feb 2009 23:46
Here's a little library I wrote to perform pixel perfect sprite collisions.

I've attached the actual source file to be included in projects, but I'll also paste the code below:



The library is pretty simple to use. Just call InitSpriteCollision() before using any of the other commands.

You are given the option of setting a transparent color by using SetTransparentColor(color as dword).

To test collision between two sprites, use SpriteCollide(spr1,spr2). There's also the option of checking a single point for collision with SpritePointCollide(x,y,spr). Currently, sprite on sprite collision does not support the scaling or offsetting of either sprite whereas point on sprite collision should be fine.

There are comments at the top of the library.

Edit: I've revised the library slightly. Now sprite on sprite collision detection supports sprite offsetting. The code snippet and attachment are updated as well.

Attachments

Login to view attachments
lucifer 1101
15
Years of Service
User Offline
Joined: 26th Jan 2009
Location: Melbourne, Australia
Posted: 1st Mar 2009 06:35
im here to be the first to say thankyou on such a great addition, and first question

what sort of impact could this have on a games perfomance especially lower end...
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 1st Mar 2009 13:16 Edited at: 11th Aug 2010 22:32
It looks good, and it'd certainly do the job, but there does seems to be a few potential logical improvements that would help reduce the overhead.

One that comes to mind, is in situations where the programmer wants to compare the same sprite to a series of sprites (the player to all the bad guys for example), or where the one sprite will knowingly always overlap the second sprite. In those situations, it'd be better to have the collision routines be able to cache the common image (in the mem block) so it's not continually copied each time a check is required. To be honest the best way around the copy overhead is to simply never copy any image. Which means building a 'collision mask' cache, rather than using the image data it self..

Another thing worth considering is how the inner most loop is structured. From what I can see, there seems to be a some redundant calculations inside the comparison loop. While it might seem superfluous. but that dead weight is magnified the more pixels you compare. For some tips on how to re-structure loop check out my post in this thread. Different subjects, but the same principals apply.

BMacZero
18
Years of Service
User Offline
Joined: 30th Dec 2005
Location: E:/ NA / USA
Posted: 4th Mar 2009 05:01
Sound cool! Unfortunately I couldn't get it to work - it acted just like the normal DBP Sprite Collision (though admittedly I didn't fiddle with it too much). Does it work with alpha transparency?

Login to post a reply

Server time is: 2024-05-02 05:22:32
Your offset time is: 2024-05-02 05:22:32