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.

DarkBASIC Discussion / Sprite collision

Author
Message
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 12th Feb 2011 19:35
I'm working on my menu maker and i've found out that there's a problem with sprite collision in dbc. if the sprite is light enough that it still gets drawn and doesn't come out as transparent, that doesn't necessarily mean it will collide with it.

Here's what i mean.

This one will get drawn without the black corners and you can collide with it using sprite collision.


This one will get drawn without the black corners, but you cannot collide with it using sprite collision.


Anyone got and explanation for this?

DVader
16
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 12th Feb 2011 22:05
No idea. What code are you using?

http://s6.bitefight.org/c.php?uid=103081
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 13th Feb 2011 07:06
This is the code. It handles buttons. All it does is check if the specified sprite is colliding with my collision dot which i position at mousex() and mousey()



DVader
16
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 13th Feb 2011 15:43
Hard to say from that bit of code, there is a lot of flag switching going on in there, which seems a little ott. But without knowing why you are changing them it's hard to say if they are really needed. I am not a fan of the sprite collision in DB and tend to to things a different way myself. Simple co-ordinate checks would be used for menus such as you are trying to make, rather than sprite collision. If you are using sprites and they are fairly square as yours are its pretty easy.
I can't see why the auto collision would fail due to the colour of the sprite though. Are both images the same format such as bmp or png? That is the only thing I can think of that can cause issues sometimes, but haven't used dbc in years, and am used to DB Pro. Also how are you testing that it is the collision causing the problem? Have you done a simple test to see if the sprites that don't seem to work can collide say, just by moving your mouse over rather than having to click?

http://s6.bitefight.org/c.php?uid=103081
Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Feb 2011 19:01 Edited at: 13th Feb 2011 19:24
@pictionary

Here's the long explanation (mostly guess work on my part, but it makes sense when observing the results).

I think it has to do with the internal programming of the sprite collision. I think internally, the goal is to have the quickest pixel overlapping detection so I think the test happens 1 color channel at a time - probably B then G then R .

If there are two sprites, the pixel positions of each are tested within calculated bounding areas based on the size and position of the two sprites. As soon as a color channel of a pixel at the same screen location is tested as non-zero for both sprites, the collision function returns as positive. So if pixel (100,100) has the Blue channel of the pixel for sprite 1 set at say 128, and sprite 2 has the blue channel for the same pixel set at 34, then that would be considered collision. If one of the two channels were Zero, that would be no collision and the test would move on to the next color channel Green.

If each sprite both have a non-zero green value set then the test is stopped and collision returns positive, otherwise there is no collision and the test then moves to the red channel.

The same test is performed.

This is nice and quick because you can just test 1 byte in any resolution and get a fast answer for collision. The problem is that it's possible to have two solid sprites of different channel colors overlap and no collision be detected. Take a look at this example. A solid red and a solid blue square will not detect collision because they have no color channels that over lap:
red = RGB(255,0,0)
blu = RGB(0,0,255)

In the following example, move the mouse to drag the red square around to see if collision is detected between it and the blue square (it won't be).



In order to solve this problem, you should make sure that both sprites contain color on all three channels or at least in the same channel for the areas that you want to collide. It order to manage 16 bit color resolution, you should try and make sure all three channels have at least 10 or 12 set as the minimum value for a channel color.

For the example in 32 bit, we could solve the collision problem by making sure the channels all have at least a 1 in them:



EDIT

I just ran another test after thinking a little more about this. The problem has to do with ANDING the two colors for the sprites. What ANDING does is compare 2 numbers and then return any matching on bits of those numbers. Everything I stated above is still valid, it just it makes things more complicated to actually detect collision. For example, if you have 2 sprites with colrs in the same channel, their bits can not match:

If two sprites had their blue channels set to 170 and 85, even though the sprites are both using blue colors channels, collision wouldn't be detected because the binary values are

10101010
01010101

Anding these would result in 0. So, it's completely possible to create multi-colored sprites that would never detect collision between each other. The only fool-proof solution I can think of beside being extremely careful in your color selection is to create your own custom routine as DVader was suggesting. However, most of the time, careful coloring of the sprites should work fine.

Enjoy your day.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 13th Feb 2011 20:02 Edited at: 13th Feb 2011 20:05
That makes perfect sense. I don't know if i should create my own function, so i'm just going to change my collision dot from solid red to solid white which should make the binaries all 11111111, so there would be no chance of collision failure. That might explain the problem i had with my 2d editor a while back. The collision kept failing and i couldn't find any faults in my code. and once again i was using solid red. Thanks latch. How you figure all this out. I will never know

EDIT:
Yup... changing the dot to white fixed the problem. turns out i won't have to write my own collision code. maybe for another program, but at the moment its good. Thanks Latch.

Login to post a reply

Server time is: 2020-08-15 11:51:25
Your offset time is: 2020-08-15 11:51:25