Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bruceuncle]

I was going to add Set Hardcol and =Hardcol() to the bug list as this has cropped up a couple of times now.  So I had a delve into the code and found the problem is that the AMOS Manual is way off track!  It's not a bug at all.   

So forget what the manual says, the correct syntax, parameters and usage are:

Set Hardcol EnableBits, MatchBits

EnableBits is a bitmap of which bitplanes you want checked.
MatchBits is a bitmap of what value to check for in each bitplane (%0 or %1).  That may sound a little strange but it just means you can check for either a set bit (%1) which is like checking for hitting a wall, or a cleared bit (%0) which is like checking for hitting a hole.

EnableBits corresponds to bits 6 to 11 in CLXCON, MatchBits corresponds to bits 0 to 5 in CLXCON.  Set Hardcol always sets bits 12 to 15 in CLXCON to %1111.  This just means that the odd numbered hardware sprites will also be included in the checks.  So effectively all hardware sprites are always included.

The problems start when you try to check the results!

Result=Hardcol(SpriteNumber)

SpriteNumber is the number of the hardware sprite you want to check.
Result is only useful if you're checking hardware sprite to hardware sprite collision when it will be -1 for a "hit".  For checking bitplane collisions, it will be zero even if you hit a bitplane pixel.  You then need to use:

Result=Col(SpriteNumber)

SpriteNumber is the number of the sprite to check for in sprite-to-sprite collisions.  BUT -1 will check for bitplane collisions.
Result would be the hardware sprite number that you hit in a sprite-to-sprite check.  Any non-zero value will be a bitplane hit if you specified -1 for SpriteNumber.

I haven't investigated whether there's any special meaning to the values returned when a bitplane collision has occurred.  I thought I'd get this and an example program posted a.s.a.p. to avoid any further confusion.  I suspect the value would indicate odd or even bitplane hits and maybe even bitplane-to-bitplane hits (useful for dual playfield).  I need to investigate a bit further....

This code (file also attached) is a quick demo of a sprite that collides with a blue box in the background but not with a pink one.  You need the collisions sprite bank from the Tutorials directory if you're just copying the code.  If you download the attachment, the bank's embedded in the program.

Code: [Select]

'==================================================
'   Demo of Hardware Sprite Collision with Bitplane
'
'   Author : bruceuncle
'     Date : 04/03/2014
'==================================================
'
'   This code just positions the screen at the same 
'   hardware coords as your Default screen: 
'
G_ADDR=Screen Base
G_XPOS=Deek(G_ADDR+82)
G_YPOS=Deek(G_ADDR+84) and $FF
For S=0 To 7
   Trap Screen Close S
Next S
Screen Open 0,320,200,8,Lowres
Screen Display 0,G_XPOS,G_YPOS,320,2000
'
'   The embedded sprite bank is the one in Tutorials used 
'   in the Collision Detection example program:
'
Get Sprite Palette : Colour 0,0 : Curs Off : Flash Off : Cls 0 : Hide On
'
'   Ink 2 means we'll be drawing in bitplane 1 (cyan colour). 
'   This is the bitplane we want to detect collisions in.
'   
Ink 2 : Box 80,80 To 239,119
'
'   Ink 1 means we'll be drawing in bitplane 0 (sorta pink colour). 
'   This is a bitplane we're not interested in.
'   
Ink 1 : Box 120,20 To 199,175

Pen 2 : Paper 0
Locate 0,23 : Centre "Press Right Mouse Key to Exit"

X=160 : Y=40 : DX=2 : DY=2
Sprite 1,X Hard(X),Y Hard(Y),2
'
'   The sprite must be masked!
'
Make Mask 1
'
'   Turn on hardware collision detection.
'   1st param is which bitplanes to turn on collision detection for.
'      Corresponds to bits 6 to 11 in the CLXCON hardware register.
'      Always set unused bitplanes to %0 in the bitmap.
'   2nd param is what value in the bitplane to check against (%0 or %1)
'      Corresponds to bits 0 to 5 in the CLXCON hardware register.         
'      Unused bitplanes have no effect in the bitmap.
'   AMOS always sets bits 12 to 15 to %1 in the CLXCON hardware register.
'   That means the odd numbered sprites will also be included in the checks.
'   So, effectively, all hardware sprites are always checked in AMOS. 
'
'   For this example we're looking for a collision with bitplane 1 so 
'   we will get a "hit" on the blue box but not on the pink one.
'   AMOS always trims leading zeros.  The value we're really loading
'   is %000010, which is a bitmap of all 6 possible bitplanes.  As our screen
'   is only 8 colours, we're only using the first three bitplanes.
' 
Set Hardcol %10,%10
'
Do
   Exit If Mouse Key=2
   Add X,DX : Add Y,DY
   If X>294 or X<26 Then DX=-DX
   If Y>174 or Y<26 Then DY=-DY
   Sprite 1,X Hard(X),Y Hard(Y),2
   '
   '   After a hit, we delay for four frames to give the sprite a chance
   '   to get clear:
   '
   If G_WAIT>0
      Dec G_WAIT
   Else
      '   
      '   Check sprite 1 for a hardware collision:
      '     
      C=Hardcol(1)
      '
      '   =Col(-1) means check for bitplane collisions (which bitplanes
      '      will be the ones we set up using Set Hardcol.
      '   0 is returned for no collision, non-zero is a collision.
      '   I haven't investigated what the actual returned values mean yet!
      '
      If Col(-1)
         '
         '   If we got a hit, I'm just jiggling the direction and sounding
         '   a ding.  The G_WAIT is just to delay the next checks until
         '   the sprite has moved away from the box a bit.  Helps prevent
         '   "head banging"!
         ' 
         Bell : DX=-DX : Add X,DX : G_WAIT=4
      End If
   End If
   Wait Vbl
Loop
'
Screen Close 0
Edit

Remember, its bitplanes that you're checking collisions with, not colour numbers.  So checking set bits in bitplane zero will register a hit for colours 1 (%000001), 3 (%000011), 5 (%000101), etc.  So you need to choose the colours in your backgrounds carefully.

[bruceuncle]

I've investigated what AMOS does with these instructions and the following applies:

Set Hardcol EnableBits, MatchBits

This remains exactly as in the previous post.

=Hardcol(SpriteNumber)
=Col(SpriteNumber)

These work a little differently.

• AMOS uses both software and hardware collision detection.  The hardware detection is only done using the Set Hardcol and =Hardcol() instructions.  However, both methods use the same results area in memory.  So you need to be careful that you don't wipe some previous results by using these instructions in any old order.  Eg.  If you check a software collision immediately after using =Harcol(), you'll wipe the hardware collision results.
• The =Col() instruction will retrieve results for both software and hardware collision detection.  But it returns a slightly different result for hardware detection, that is, after a =Harcol() instruction.  This is described below.
• For hardware collision detection, AMOS reads the CLXDAT hardware register.  So when you use =Harcol(), it reads that register and puts the results into its own format so you can use =Col() to retrieve them.  However, the CLXDAT register is cleared every time it's read.  So you should only use =Harcol() once per test.  After that, you can use =Col() as many times as you need to get at the results as AMOS has cached them in it's own format in its own memory space.
• AMOS keeps its own list of collisions in a bit array in 8 longwords.  Giving 256 possible object hits !!!???  This is what =Col() is reading.  It simply indexes into that array using the number you've provided as a parameter and examines the bit it finds there.  If you feed it a negative number (-1 is the usual one) it examines every bit from that number  upwards until it finds one that's set (%1) and returns its index number in the array.  That number may be useful in some situations but I can't think of one yet  .
• There can be situations in Dual Playfield modes where you want to check for a collision between the two playfields.  =Hardcol(-1) does this (see below) but in doing so it clears CLXDAT.  Meaning that you can't check for both a playfield-to-playfield hardware collision and any other hardware collision at the same time.

So these are the parameters and results for the two instructions:

Result=Hardcol(SpriteNumber)

	SpriteNumber	Result
	0 thru 7	Checks all possible hardware collisions for the specified SpriteNumber and returns -1 for a sprite-to-sprite collision.  Returns 0 for a sprite to playfield collision.  Saves the results (which sprite or bitplane was hit) for =Col() to use to retrieve the sprite number that was hit or whether a playfield was hit.
	-1	Checks only for a playfield-to-playfield collision and returns -1 for a hit and 0 for no hit.  No need to use =Col() to retrieve any results.  Note that this also clears AMOS's own collision table used by =Col() so there's no point in trying to use that instruction anyway!

Result=Col(SpriteNumber)

	SpriteNumber	Result
	0 thru 7	Will return -1 if the specified SpriteNumber was hit and 0 for no hit.  Note that the sprite numbers are paired due to Set Hardcol always enabling both odd and even sprites numbers.  So if you get a hit for, say, sprite 2, you'll always also get a hit for sprite 3, and so on.  There's no way to tell which one of each pair is involved.
	8 thru 11	Will return -1 if a bitplane hit has been detected.  Values of 8 or 9 check for an odd numbered bitplane hit, values of 10 or 11 check for an even numbered bitplane hit.  It doesn't matter which number you use in each pair, it's just a quirk caused by that sprite number pairing mentioned above.  As the odd versus even bitplane number checking is only relevant in Dual Playfield mode, using any value from 8 thru 11 appears to work in single playfield modes.  (Can any hardware expert out there verify that this is the way CLXDAT is supposed to work?)
	-1 thru -255	Will work through AMOS's table of collision results and return the sprite number (sic) for the first collision it finds (where a bit = %1).  It will start at whatever number is specified in SpriteNumber (converting it to a positive number first).

That's all folks!  Now all I've got to do is get the documentation up to date again  .

[Lonewolf10]

Great work there bruceuncle

I have never used sprite collision detection before, but if I do I now have a working example

[gibs]

Hi Bruce Uncle.
Thanks for the documentation.
However I have a question:
In your example, if I use "Ink 4" instead of "Ink2", so I am on the 3rd bit plane, right ?
So I need to set "Set Hardcol %100,%100"

But if I do that, the ball also detect collision in bit plan 0.

I also tried "Set Hardcol %1,%1", same result.

Thanks.

[bruceuncle]

Hi Bruce Uncle.
Thanks for the documentation.
However I have a question:
In your example, if I use "Ink 4" instead of "Ink2", so I am on the 3rd bit plane, right ?
So I need to set "Set Hardcol %100,%100"

But if I do that, the ball also detect collision in bit plan 0.

I also tried "Set Hardcol %1,%1", same result.

Thanks.

Oops!     There should have been an updated attachment on that last post.  The first version of the example worked for bitplane 1, but only by luck!  (Well, I did say I hadn't worked out what all the replies were in that example post...)  The culprit  was my using =Col(-1).

The full description of the usage is in that previous post.

I've attached the updated version and the code's here.   You need the collisions sprite bank from the Tutorials directory if you're just copying the code.  If you download the attachment, the bank's embedded in the program.

Code: [Select]

'==================================================
'   Demo of Hardware Sprite Collision with Bitplane
'
'   Author : bruceuncle
'     Date : 05/03/2014
'==================================================
'
'   This code just positions the screen at the same 
'   hardware coords as your Default screen: 
'
G_ADDR=Screen Base
G_XPOS=Deek(G_ADDR+82)
G_YPOS=Deek(G_ADDR+84) and $FF
For S=0 To 7
   Trap Screen Close S
Next S
Screen Open 0,320,200,8,Lowres
Screen Display 0,G_XPOS,G_YPOS,320,2000
'
'   The embedded sprite bank is the one in Tutorials used 
'   in the Collision Detection example program:
'
Get Sprite Palette : Colour 0,0 : Curs Off : Flash Off : Cls 0 : Hide On
'
'   Ink 2 means we'll be drawing in bitplane 1 (cyan colour). 
'   This is the bitplane we want to detect collisions in.
'   
Ink 2 : Box 80,80 To 239,119
'
'   Ink 1 means we'll be drawing in bitplane 0 (sorta pink colour). 
'   This is a bitplane we're not interested in.
'   
Ink 1 : Box 120,20 To 199,175

Pen 2 : Paper 0
Locate 0,24 : Centre "Right Mouse Button to Exit"

X=160 : Y=40 : DX=2 : DY=2
'
'   Must be a hardware sprite (0 thru 7) not a computed one:
'
Sprite 1,X Hard(X),Y Hard(Y),2
'
'   The sprite must be masked!
'
Make Mask 1
'
'   Turn on hardware collision detection.
'   1st param is which bitplanes to turn on collision detection for.
'      Corresponds to bits 6 to 11 in the CLXCON hardware register.
'      Always set unused bitplanes to %0 in the bitmap.
'   2nd param is what value in the bitplane to check against (%0 or %1)
'      Corresponds to bits 0 to 5 in the CLXCON hardware register.         
'      Unused bitplanes have no effect in the bitmap.
'   AMOS always sets bits 12 to 15 to %1 in the CLXCON hardware register.
'   That means the odd numbered sprites will also be included in the checks.
'   So, effectively, all hardware sprites are always checked in AMOS. 
'
'   For this example we're looking for a collision with bitplane 1 so 
'   we will get a "hit" on the blue box but not on the pink one.
'   AMOS always trims leading zeros.  The value we're really loading
'   is %000010, which is a bitmap of all 6 possible bitplanes.  As our screen
'   is only 8 colours, we're only using the first three bitplanes.
' 
Set Hardcol %10,%10
'
Do
   Exit If Mouse Key=2
   Add X,DX : Add Y,DY
   If X>294 or X<26 Then DX=-DX
   If Y>174 or Y<26 Then DY=-DY
   Sprite 1,X Hard(X),Y Hard(Y),2
   If G_WAIT>0
      '
      '   After a hit, we delay for four frames to give the sprite a chance
      '   to get clear:
      '
      Dec G_WAIT
   Else
      '   
      '   Check sprite 1 for a hardware collision.  The results go into AMOS's
      '   internal collision table.
      ' 
      C=Hardcol(1)
      '
      '   Display positions 8 thru 15 from AMOS's collision table:
      '
      Locate 0,23 : For I=8 To 11 : Print Hex$(Col(I),2); : Next I
      '
      '   =Col(8) or =Col(9) means "check for the sprite colliding with an
      '                             even-numbered bitplane specified in
      '                             Set Harcol"
      '   =Col(10) or =Col(11) means "check for the sprite colliding with an
      '                               odd-numbered bitplane specified in
      '                               Set Harcol"
      '
      '   0 is returned for no collision, -1 is a collision.
      '
      '   The above applies to dual playfield mode.
      '   In single playfield mode, it doesn't matter what you use. 
      '
      If Col(8)
         '
         '   If we got a hit, I'm just jiggling the direction and sounding
         '   a ding.  The G_WAIT is just to delay the next checks until
         '   the sprite has moved away from the box a bit.  Helps prevent
         '   "head banging"!
         ' 
         Bell : DX=-DX : Add X,DX : G_WAIT=4
      End If
   End If
   Wait Vbl
Loop
'
Screen Close 0
Show On
Edit


[gibs]

Thanks for the quick answer
But I have another question:

In your updated example, let's draw a (red) line in the 3rd biplane using color 7.
Colour 7,$F00: Ink 7: Draw 80,150 to 239,150

Then the detection is also activated to this bit plane, which is weird as we set it in the 2nd bit plane only.

[bruceuncle]

In your updated example, let's draw a (red) line in the 3rd biplane using color 7.
Colour 7,$F00: Ink 7: Draw 80,150 to 239,150

Then the detection is also activated to this bit plane, which is weird as we set it in the 2nd bit plane only.

Ah, you're confusing colour numbers with bitplanes.  Colour 7 is all bitplanes (7 = %111).  So if you just want a single bitplane, you'd use Colour 1 (%001 - the first bitplane), Colour 2 (%010 - the second bitplane) or Colour 4 (%100 - the third bitplane).  Colour 0 (%000) is no bitplanes.  Colours 3, 5, 6 & 7 (for an 8 colour screen) all set pixels bits in more than one bitplane, so you'll register 'hits' in any of those bitplanes.

The Amiga's bitplane display format means it's no easy task to decide what colours you need and how to turn them into what bitplanes to use.  Hardware sprite/bitplane collision detection complicates that task.  It becomes even more complex for dual playfield screens.  You have to carefully plan your colour and bitplane usage.

[gibs]

Oh ok thanks 

[Hungry Horace]

bruceuncle, your example is really nice, and it been of some help to me understanding the commands.

I am still always very hazy when it comes to bitplaces / bitmaps etc. though.  I kind of get the prinicple (how the colours are made up of true/false values in each place combining) ... my problem is understanding the application.

So my game is running with a 16 colour image as the background - great. This uses up planes 0-3 . Detecting collision based on colours or from useage of colours within that background isnt really practical.  4 hardware Sprites are being used and are 16x16 in size, taking advantage of colours 16-31.

Lets say I only have 3 'states' i want to check for.  One creates a 'no go' zone. One slows my hero down and the the last one slows them down and causes damage.

Is it possible to create a new 'invisible' image (btimap?) which i can check my sprites against?  If so, how do i open it / reference it?  Can i have it on a logical screen whilst the player only sees the 'drawn only one' physical screen?

Can i use another plane as a 'mask' to hide my hero behind and create the illusion of going behind another object? (see the Serious F1 thread)....



Thank you for any help/advice!!!

[bruceuncle]

I am still always very hazy when it comes to bitplaces / bitmaps etc. though.  I kind of get the prinicple (how the colours are made up of true/false values in each place combining) ... my problem is understanding the application.

Thank you for any help/advice!!!

Yeah, I have to stop and draw myself pictures every time I have to think about collisions, sprites, colour maps and bitplanes.  Both the Amiga's strength (at the time) and its weakness, in that it takes a lot of planning to get what you want out of it.  At least AMOS makes it easier to set up and test rather than doing it in C or Assembler.

I'm still up to my neck in Resource macros - they work great but programming in them can be a nightmare.  I wasted a whole Sunday's worth of "quality Amiga time" the weekend before last trying to track down why some macros worked sometimes and not others.  The tip in the docs of using Resource itself to extract the binary from a load file was the culprit.  AmigaDOS  saves in multiples of longwords, so sometimes there's and extra zero word at the end which makes Resource think it's hit the next macro in the list and lock-up or Guru follows...  Laugh?  I could have cried.   

Anyways, enough idle (sic) chit chat.  I'll have a look as soon as the Resource work is out of the way and we've got sources for all Lonewolf10's extensions collection.  (Which all helps me understand how people have used amos.library and AMOSPro.Lib so's none of the bug fixes or enhancement thought bubbles will stuff anything up.)  So, if you'll excuse the cliché, "I'll get back to you."