OCS collision and clx registers

[PiCiJi]

it seems collision detection isn't documented that well. I have a few understanding questions.

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?

CLXDAT bits 8 - 5: are these bits considered in single playfield mode?

Is sprite collission detected if the transparent pixel of 2 sprites overlap?

[Toni Wilen]

Originally Posted by PiCiJi

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.

[pandy71]

Comparison schematic (simplified but should give overall idea how it is performed internally in IC) is provided in USPTO 4874164 on page 10 (fig. 12)

[Toni Wilen]

It can't get any more simplified than that. It shows nothing except the obvious, each "plane" of sprite and each bitplane (including inverted data, probably to handle "match" value matching) goes to black box. No number of planes information, no dual playfield mode informartion. Useless.

[pandy71]

There is also description inside document but i agree - there no detailed information - similar as for other HW as for example line mode.

[Photon]

Just wanted to say that for games, sprite collision registers seem to go largely unused. There are many reasons. Sprite collision is pixel-perfect and sometimes you want something more forgiving, or simply collide only the "main body" of an object, even if pixels are set outside the body in the sprite. Also, using it forces you to use sprites for the colliding object, and in many games there aren't enough sprites to go around, or objects are larger than sprites. AGA allows bigger sprites, so there it may possibly be of more use, but still, using sprites enforces some limitations you'll overcome by using bobs instead, and so that's what many use, not sprites.

Also, a fast moving sprite like a bullet might "skip past" another sprite like a spaceship, or at least the corner of it, where in fact the spaceship was in the bullet's path and should have exploded. This is especially true if the frame rate is less than 50 FPS. And so the programmers, if they used sprites for both, would still have to write a separate collision routine from coordinates and hitboxes.

In short, sprite collision is pretty much useless except in rare special cases, and hitboxes is the way to go. You can also do pixel-perfect collision detection from the bob outlines. Then you could use hitboxes as a quick-check to decide whether you need to spend time blitting to check pixels.

Another bonus from not using sprite collision is that you won't have to wait for the collision bit to be set, but can just check if two objects collide anytime and make decisions in the right place in the game code.

[mc6809e]

Originally Posted by Photon

Just wanted to say that for games, sprite collision registers seem to go largely unused. There are many reasons.

I think the original Amiga design called for an Atari 2600-like super game console with 128K RAM. Hardware sprites and collision registers are used extensively on the 2600.

Of course a machine with 256K or 512K and a blitter turned out to be so much more powerful that the sprite system was mostly obsoleted.

I've tried to think of a way the sprites and collision registers might be useful for certain calculations. I haven't come up with anything, but the idea would be to set aside a number of lines in the vertical overscan area with all palette registers set the same as the background color. Then with the proper setting of sprite positions and values, and maybe something in the playfields, some useful calculation might be performed.

[NorthWay]

Originally Posted by mc6809e

I think the original Amiga design called for an Atari 2600-like super game console with 128K

Have you looked at the 2600->A8->OCS evolution?

2600 has registers that _you_ feed.
A8 can be pointed at data and then it runs continuously.
OCS has control structures that waits and syncs before updating the registers.

In many ways the evolution is clear between them. Blitterlists were the next logical step, but AAA sunk with C=.

[Photon]

Yeah, my post was just intended as a heads-up for those who want to implement collision detection and mistakenly might think they have to use the very limited hardware collision detection.

[PiCiJi]

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

ok I would assume if plane is enabled in clxcon but disabled in bplcon0, 0 is compared with the "match" value.

and i would assume if even planes are already shifting and odd planes still delayed by bplcon1, 0 is compared with the "match" value for odd planes (and vice versa)

for playfield to playfield collisions above code should be valid too. (exception: if (dualplayfield) match=true ) if the match variable after the loop keeps true, bit 0 in clxdat should be set?

[earok]

This is a very dumb question, but - is there a way, assuming AGA dual playfield (4 bitplanes foreground + 4 bitplanes background = 8 bitplanes total), of ensuring that a collision on the foreground layer will always be detected with the CLXCON registers? So long as there was a bit set on any of the four foreground planes, and not just assuming one in particular?

From my reading of the above (my understanding may be completely wrong), I would guess not, and the best I could hope for is to catch collisions with half of the colors.


Edit: Maybe I'm overthinking this.. is it as simple as setting CLXCON/CLXCON2 for each of the four bitplanes, and then checking the resulting collision data? Or can it all be done at once?

[Auscoder]

Originally Posted by earok

This is a very dumb question, but - is there a way, assuming AGA dual playfield (4 bitplanes foreground + 4 bitplanes background = 8 bitplanes total), of ensuring that a collision on the foreground layer will always be detected with the CLXCON registers? So long as there was a bit set on any of the four foreground planes, and not just assuming one in particular?

From my reading of the above (my understanding may be completely wrong), I would guess not, and the best I could hope for is to catch collisions with half of the colors.


Edit: Maybe I'm overthinking this.. is it as simple as setting CLXCON/CLXCON2 for each of the four bitplanes, and then checking the resulting collision data? Or can it all be done at once?

Sorry/not sorry to resurrect this somewhat rusty thread. I am just touching on using CLXDAT in conjunction with some bounding box detection.

It seems that to have the Amiga register a collision there must be an exact match for the bit pattern set in the CLXCON polarity bits. ie. Pattern must be explicit