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.

Dark GDK / very close pixel perfect (almost...)

Author
Message
xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 3rd Apr 2010 02:31 Edited at: 3rd Apr 2010 05:37
-------------------------------
UPDATED THREAD 4/2/2010 10:36pm
-------------------------------
-Verified readPixel() to accurately count pixels in bitmap image
--Have not verified with animations yet...Once we have this, we should be good





With the code below, and using darkGDK, you will be able to get PIXEL PERFECT COLLISIONS for 2D games. But only one thing remains in the way....I can\\\\\\\'t seem to find what is messing up in my collision function...have a look:

STEVE\\\\\\\'S getPixel() function (gamedev.net)





My almost complete pixel collision...I kid you knot, I had this almost working(perfect) last night...someone threw a wrench into it.




I can show you how to implement this in your game as well, I have created a TEST game (2 sprites, 1 animated, 1 still).

Ask questions, post feedback

Thanks.
xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 3rd Apr 2010 04:21 Edited at: 3rd Apr 2010 07:25
I believe the problem is that in my call to readPixel(), the function cannot tell the difference between my opaque and non opaque colors (this is due to the function call dbSetImageColorKey() earlier in the code). This would result in me only getting a vector full of 1's (for opaque) and no 0's (non opaque). The result would be the same collision detection that darkGDK has already implemented.


So, to figure this out, I need the have 2 things:

1. Need to know how they set up the createAnimatedSprite() function.

2. Need a way to change the image key color for a microsecond to check for collision
haliop
User Banned
Posted: 3rd Apr 2010 08:23
you know what i'll would do if i knew how?

i'll do Polygon Collision rather then pixel perfect only that
i'll use pixel perfect algo to find those Polygons.

like if you have a sprite of a ball, pixel perfect will determine where the sprite color is + and where alpha is -

once it has all of that in memory , it will "draw" polygons or just the lines(debug) of it , and then you can do a Static Geometry collision which will work pretty fast.

last year i was building a 2D top down shooter with vehicles
so i had this friend from the U.S who helped me with it , i dont have the code , but that was awesome altough he didnt used the Pixel Perfect algo , but whenever you add a sprite you just need to configure its polygons , and its all working really smooth , and if i remmber correctly it was about 50 lines of code nothing much , but working awesome.
xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 3rd Apr 2010 08:39
well, if it gets me out of this mud i'm stuck in...I'm gonna search that static geometry....probably could have had that easy

btw...i'm close to the pixel perfect..but i can settle for less
JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 3rd Apr 2010 18:48
Are you sure that the pixel format is D3DCOLOR_XRGB? If you are making that assumption, you could be wrong. I haven't dealt with DX in particular lately, but (way back when) if you were running with dbSetWindowOn() your pixel format would take on the compatible desktop format (and not necessarily the requested format). Perhaps this is the case here? Additionally, if memory serves, the bitsperpixel/bytesperpixel values could vary in the same way...

Finally, while trying to help track down the bug you describe, I've taken the liberty of rewriting it. The rewrite should provide significant gains in performance once you get it working - the reasons are described in the code - however, I've not tested it and so it may be a bit buggy (i used your existing code as a base).

With that being said, with the exception of the possible color format change, I really can't see anything wrong (assuming colors are as you expect)...

Hope you like the modifications:




JTK
xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 3rd Apr 2010 21:12 Edited at: 4th Apr 2010 00:52
EDIT:

Error is math related. I have no idea why i'm having so much trouble with this. In the very last nested for loops, the sprite's adjusted pixel is off. I'm looking into it now
xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 3rd Apr 2010 21:42 Edited at: 4th Apr 2010 00:10
EDIT:

I fixed the initial check to see if there was even a rectangular box collision.

Currently working on getting the sprites to move a little bit closer...VERY GOOD!

xbandages
14
Years of Service
User Offline
Joined: 30th Mar 2010
Location: Michigan
Posted: 4th Apr 2010 02:13 Edited at: 4th Apr 2010 14:31
The other problem we have to look at now is that I have PIXEL PERFECT in the TOP LEFT quadrant of image (so i'm moving towards the top right of another sprite). This should only be a series of if statements to check which direction we are coming from.

stay tuned!

Login to post a reply

Server time is: 2024-10-02 03:37:23
Your offset time is: 2024-10-02 03:37:23