English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 06 July 2014, 17:33   #1
PiCiJi
Registered User
 
Join Date: Sep 2003
Location: germany
Age: 40
Posts: 265
OCS collision and clx registers

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?
PiCiJi is offline  
Old 19 July 2014, 19:46   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,272
Quote:
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.

Quote:
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.

Quote:
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)

Code:
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.

Quote:
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 offline  
Old 19 July 2014, 21:37   #3
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,690
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)
pandy71 is offline  
Old 20 July 2014, 14:31   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,272
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.
Toni Wilen is offline  
Old 21 July 2014, 01:28   #5
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,690
There is also description inside document but i agree - there no detailed information - similar as for other HW as for example line mode.
pandy71 is offline  
Old 26 July 2014, 22:17   #6
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,772
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.
Photon is offline  
Old 26 July 2014, 23:54   #7
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 304
Quote:
Originally Posted by Photon View Post
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.
mc6809e is offline  
Old 27 July 2014, 01:41   #8
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 613
Quote:
Originally Posted by mc6809e View Post
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=.
NorthWay is offline  
Old 27 July 2014, 02:49   #9
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,772
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.
Photon is offline  
Old 17 August 2014, 20:19   #10
PiCiJi
Registered User
 
Join Date: Sep 2003
Location: germany
Age: 40
Posts: 265
Quote:
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?
PiCiJi is offline  
Old 08 September 2018, 07:49   #11
earok
Registered User

 
Join Date: Dec 2013
Location: Auckland
Posts: 2,152
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?

Last edited by earok; 08 September 2018 at 13:15.
earok is offline  
Old 30 July 2019, 07:15   #12
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 21
Quote:
Originally Posted by earok View Post
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
Auscoder is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Collision detection: 2 doubts nandius_c Coders. Asm / Hardware 6 30 November 2014 01:53
Sprite movement and Collision Routine Blip Coders. General 35 14 February 2011 01:00
Using FPU registers? oRBIT Coders. General 16 26 April 2010 14:34
Slamtilt and RTC collision Predseda support.Games 5 22 August 2009 23:28
Gayle Hardware Registers bluea support.Hardware 5 09 July 2006 18:07

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:51.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08711 seconds with 15 queries