View Single Post
Old 19 July 2014, 18:46   #2
Toni Wilen
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,068
Originally Posted by PiCiJi View Post
it seems collision detection isn't documented that well. I have a few understanding questions.
It isn't. I examined this long time ago and emulation should be 100% correct but I am not sure how to explain it because internally it also isn't that simple.

CLXCON bits 11 - 0: Have these bits any influence to sprite collisions or is it considered for playfiled to playfield only? Or maybe playfield doesn't matter, only even and odd bitplanes matters?
Bits 1 to 11 affect both playfield to sprites and playfield to playfield collisions.

CLXDAT bits 8 - 5: are these bits considered in single playfield mode?
Both single and dual. Note that documentation is wrong, there is a difference between single and dual playfield mode.

Emulation code does it this way (probably easier to explain than guessing how hardware actually does it, which of course needs totally different implementation)

match = true
loop twice (first select odd planes, next select even planes)
 if (dualplayfield)
   match = true
 check plane collision condition (odd or even planes, enabled plane's bit pattern == "match" value?)
 if no bitplane collision: match = false
 if (match == true) set sprite collision bit in CLXDAT if non-zero sprites in same bitplane pixel position
end loop
I have no idea why it works like this.. It has strange side-effect in single playfield mode: even fields can never match without odd fields also matching but opposite is possible.

And finally, CLXDAT bit 15 ("not used") is always set for some reason.

Is sprite collission detected if the transparent pixel of 2 sprites overlap?
No, transparent color (sprite pixel value 0) does not cause collisions.
Toni Wilen is online now  
Page generated in 0.04180 seconds with 11 queries