English Amiga Board


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

 
 
Thread Tools
Old 05 April 2016, 13:52   #1
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Hardware collision detection in Amiga games?

Hi everyone! How do you think collision detection was mainly done in Amiga games? Do you think hardware collision detection was a common way to do it? I believe it was mainly done by software (using AABB in some cases maybe?) but I'm just guessing... what do you think?

Thanks in advance!
nandius_c is offline  
Old 05 April 2016, 14:17   #2
S0ulA55a551n
Registered User
S0ulA55a551n's Avatar
 
Join Date: Nov 2010
Location: Rhondda, Wales
Age: 41
Posts: 514
Didn't hardware detection collisions only work with sprites and most of the time bobs were used due to the limited number of sprites ?
S0ulA55a551n is offline  
Old 05 April 2016, 14:29   #3
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by S0ulA55a551n View Post
Didn't hardware detection collisions only work with sprites and most of the time bobs were used due to the limited number of sprites ?
Basically, hardware collision detection can be used between sprite pairs, between those pairs and both playfields and between the playfields themselves. It's a little more complicated than that, though .

Last edited by nandius_c; 05 April 2016 at 16:01.
nandius_c is offline  
Old 05 April 2016, 18:21   #4
Apollo
Registered User

Apollo's Avatar
 
Join Date: Sep 2008
Location: Germany
Age: 44
Posts: 125
Additionally there is the 'blitter zero flag' but I don't know if that was used by any game in the past.

I remember that there was a thread here on eab with a quite interesting discussion about this question. AFAIR the outcome was that most people did a more or less sophisticated comparison of the objects rectangles.
Apollo is offline  
Old 05 April 2016, 18:27   #5
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by Apollo View Post
Additionally there is the 'blitter zero flag' but I don't know if that was used by any game in the past.

I remember that there was a thread here on eab with a quite interesting discussion about this question. AFAIR the outcome was that most people did a more or less sophisticated comparison of the objects rectangles.
You're right, there's also the possibility of checking collisions using de Blitter zero flag, I forgot to mention that... who knows if it was ever used in any Amiga game! I'll try to find that thread you mentioned.
nandius_c is offline  
Old 05 April 2016, 18:43   #6
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 631
Quote:
Originally Posted by nandius_c View Post
You're right, there's also the possibility of checking collisions using de Blitter zero flag, I forgot to mention that... who knows if it was ever used in any Amiga game! I'll try to find that thread you mentioned.
I'm pretty sure I read an interview with the programmer of Menace where he described using 'a special feature of the Blitter' to check for collisions. My guess is that he used the zero flag.

If you ask me, the problem with using the Blitter for collision checks is not just performance though, you also get (unless you make smaller collision masks) pixel-perfect collision detection and this is usually not what you really want*. In most 16 bit and later games players get a bit more leeway than that.

*) Ironically, in my experience a lot of people say they do want pixel perfect collisions when playing a game but then go on to complain about games which use such methods saying they are unfairly difficult
roondar is offline  
Old 05 April 2016, 18:55   #7
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by roondar View Post
I'm pretty sure I read an interview with the programmer of Menace where he described using 'a special feature of the Blitter' to check for collisions. My guess is that he used the zero flag.

If you ask me, the problem with using the Blitter for collision checks is not just performance though, you also get (unless you make smaller collision masks) pixel-perfect collision detection and this is usually not what you really want*. In most 16 bit and later games players get a bit more leeway than that.

*) Ironically, in my experience a lot of people say they do want pixel perfect collisions when playing a game but then go on to complain about games which use such methods saying they are unfairly difficult
You remember correctly, I've checked the book 'The future was here' and the programmer of Menace says they used the Blitter for checking collisions .

Personally, I don't like the idea of "wasting" Blitter DMA time for checking collisions (something that can be done with the CPU) though I understand that's not always the best solution. And I absolutely agree with you: most players don't want pixel-perfect collision detection.
nandius_c is offline  
Old 05 April 2016, 19:06   #8
S0ulA55a551n
Registered User
S0ulA55a551n's Avatar
 
Join Date: Nov 2010
Location: Rhondda, Wales
Age: 41
Posts: 514
Think what payers want is pixel perfect collision detection with platforms and background etc but not with enemies
S0ulA55a551n is offline  
Old 05 April 2016, 21:03   #9
nogginthenog
Amigan

 
Join Date: Feb 2012
Location: London
Posts: 677
Quote:
Originally Posted by nandius_c View Post
Personally, I don't like the idea of "wasting" Blitter DMA time for checking collisions
Does DMAF_BLTNZERO add any extra overheads? Just wondering.
nogginthenog is offline  
Old 05 April 2016, 21:51   #10
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Belgrade, Serbia
Posts: 319
Always used bounding box to bounding box collision checks in my games
DanScott is offline  
Old 06 April 2016, 00:34   #11
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by nogginthenog View Post
Does DMAF_BLTNZERO add any extra overheads? Just wondering.
I think that using the blitter for checking collision detection would mean doing some extra blits for every couple of BOBs we want to check. Here you can read an interesting article with many details about using the blitter in an Atari Falcon for doing collision detection.
nandius_c is offline  
Old 06 April 2016, 00:40   #12
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by DanScott View Post
Always used bounding box to bounding box collision checks in my games
Good to hear that, as I'm determined to use AABB for my games too.

Thanks, Dan!
nandius_c is offline  
Old 06 April 2016, 01:17   #13
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 869
Quote:
Originally Posted by DanScott View Post
Always used bounding box to bounding box collision checks in my games
A friend of mine hardcore gamer might point you as Evil for that - ok, usually more than it is not needed but in some case bounding box was executed VERY badly as in team 17 or Tiertex stuff...
saimon69 is offline  
Old 07 April 2016, 00:00   #14
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,591
Quote:
Originally Posted by nogginthenog View Post
Does DMAF_BLTNZERO add any extra overheads? Just wondering.
Not the flag itself, but if you need to blit contours into an offscreen buffer to make it pixel-perfect, it costs that blit. With bob to bob collision detection (in their own bitplanes/playfields), you get it for free, though.

The problem is you get the result too late Or at least I would want collisions to be detected before drawing, say, a non-exploded enemy, so that I can instead draw the exploded one. If you don't check before moving stuff, you get 1 frame lag on detection.

If you want pixel-perfect collision detection, this or sprite collision is the only real way to do it. (Sprite collision also reports 1 frame too late.) Just do a bounding box check first and if that collides, do the pixel-perfect check else not.

You can make life easier by setting up the playfields, sprites or bitplanes in a way that will make it easy and a little faster. In many cases this means that if graphics are already drawn you have some adjustments to do to the graphics. You get a better result if the specs are laid down before drawing starts, although you may get around it with the palette remap feature of DPaint.

If you're not making a shooter or other game with lots of sprites/bobs moving, this is the most accurate method.

~

Otherwise bounding boxes work okay for regular shapes, only make it a little bit smaller than the sprite to avoid false positives. The player sprite is the most important one to not get false positives on.

For small bullets you can do a bit test in the relevant bitplanes or in the mask bitplane of the player sprite. Just remember that objects moving at speeds of close to the width of the target can skip past the target! (This is valid for all forms of collision detection.) This means that framerate is a factor, as with Xenon 2's or Project X's abysmal collision detection because with each framerate decrease, the objects have to move that much faster per second.

For relatively regular objects, you can also use radius. All it takes is a multiplication table and the rule of Pythagoras, only the distance you check against is the radius squared to avoid the square root. It's faster than a bounding box check.

Under no circumstances must you allow another object to move influenced by the movement of the player sprite, before checking collisions. That would not be a serious flaw, that would be a failed game design.

/rant This makes me want to code another game!! Argh
Photon is offline  
Old 07 April 2016, 01:30   #15
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by Photon View Post
Otherwise bounding boxes work okay for regular shapes, only make it a little bit smaller than the sprite to avoid false positives. The player sprite is the most important one to not get false positives on.
I absolutely agree, this is exactly what I'm planning to do for my projects .

Quote:
Just remember that objects moving at speeds of close to the width of the target can skip past the target! (This is valid for all forms of collision detection.)
This is something I already experienced in previous projects and I'm not sure about how to solve it yet... If a bullet is moving at 3 pixels per frame, for example, would it make any sense checking collisions at those three positions of the bullet's movement? In another thread I opened some years ago Mrs. Beanbag suggested to use line intersections (http://eab.abime.net/showthread.php?t=71288). Ideas?

Quote:
For relatively regular objects, you can also use radius. All it takes is a multiplication table and the rule of Pythagoras, only the distance you check against is the radius squared to avoid the square root. It's faster than a bounding box check.
I was thinking of using radius to check collisions between the player sprite and the enemies bullets (circles), for instance.

Quote:
/rant This makes me want to code another game!! Argh
Which game did you code? I'd like to see that!

Thank you, sensei!
nandius_c is offline  
Old 07 April 2016, 03:46   #16
invent
pixels

invent's Avatar
 
Join Date: May 2014
Location: Australia
Age: 47
Posts: 191
Back when we started working on Amiga games in the 80's we had two methods of collision detection.

- Box method
- Colour (usually dark, not magenta as shown the image)

Not sure which was most efficient but the colour pixel method was more accurate. The Box method with some tweaking worked well had ten options in the custom editor with no collision as one of the options..

Attached Thumbnails
Click image for larger version

Name:	collision.png
Views:	694
Size:	76.2 KB
ID:	48132  
invent is offline  
Old 07 April 2016, 12:40   #17
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Belgrade, Serbia
Posts: 319
For collision with the backgrounds, we flagged each 16x16 block with it's collision type ie. Solid, No Collision, Solid from above (for platforms you could jump up through but land on top of)

We then had slope tables for background blocks (16 bytes) defining the height at each horizonal pixel (for slopes etc.). It worked pretty well, and obviously was quick to process, as we didn't need to check lots of bounding boxes against the player, and enemies etc..
DanScott is offline  
Old 07 April 2016, 23:25   #18
nandius_c
Fernando Cabrera

 
Join Date: Oct 2013
Location: Spain
Posts: 86
Quote:
Originally Posted by invent View Post
Back when we started working on Amiga games in the 80's we had two methods of collision detection.

- Box method
- Colour (usually dark, not magenta as shown the image)

Not sure which was most efficient but the colour pixel method was more accurate. The Box method with some tweaking worked well had ten options in the custom editor with no collision as one of the options..
Thanks for such an interesting comment! I've been seriously thinking of trying a mixed solution between hardware collision detection and boxes, doing something similar to what can be seen in your example, though it obviously has some impact on the graphic design process. If sprites 0 and 1 (for example) are used for the player and the rest of the sprites are used for enemy bullets, it would not be necessary checking collision for those 2 types of elements by software (except when the hardware collision detection system signals a collision, of course).

P.D: sorry to ask but... which game are those graphics from?
nandius_c is offline  
Old 08 April 2016, 00:45   #19
invent
pixels

invent's Avatar
 
Join Date: May 2014
Location: Australia
Age: 47
Posts: 191
Hi nandius_c,

Thanks, the graphics are from this game
invent is offline  
Old 08 April 2016, 00:54   #20
Retro1234
Bo Bo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 3,988
I wouid guess for backgrounds just boxing a map exitior in reverse any other is only useful for enemy+enemy.
or when math check correct then do blit check for 100% shape check.
I never liked the idea of colour collision was it ever used in a commercial game?

Last edited by Retro1234; 08 April 2016 at 02:46.
Retro1234 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
Games that actually used the Amiga hardware amiga Retrogaming General Discussion 54 27 February 2010 18:36
what games need 'full' collision level ? kirk support.WinUAE 25 07 February 2010 03:01
original amiga games and hardware for sale cookieninja MarketPlace 1 12 September 2006 16:37
FS: Lots of Amiga hardware and games and apps ungi MarketPlace 9 16 June 2006 21:48

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 08:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.11524 seconds with 14 queries