@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).
set display mode 800,600,32
sync on
sync rate 0
hide mouse
rem make a blue box
cls 255
get image 1,0,0,100,100
sync
rem make a red box
cls rgb(255,0,0)
get image 2,0,0,100,100
sync
rem clear screen to black
cls 0
ink rgb(255,255,255),0
sprite 1,200,200,1
sprite 2,mx,my,2
do
cls
text 0,0,"Sprite collision = "+str$(sprite collision(1,2))
sprite 1,200,200,1
mx=mousex()
my=mousey()
sprite 2,mx,my,2
sync
loop
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:
set display mode 800,600,32
sync on
sync rate 0
hide mouse
rem make a blue box
cls rgb(1,1,255)
get image 1,0,0,100,100
sync
rem make a red box
cls rgb(255,1,1)
get image 2,0,0,100,100
sync
rem clear screen to black
cls 0
ink rgb(255,255,255),0
sprite 1,200,200,1
sprite 2,mx,my,2
do
cls
text 0,0,"Sprite collision = "+str$(sprite collision(1,2))
sprite 1,200,200,1
mx=mousex()
my=mousey()
sprite 2,mx,my,2
sync
loop
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.