Hardware collision detection in Amiga games?

[nandius_c]

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!

[S0ulA55a551n]

Didn't hardware detection collisions only work with sprites and most of the time bobs were used due to the limited number of sprites ?

[nandius_c]

Originally Posted by S0ulA55a551n

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 .

[Apollo]

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.

[nandius_c]

Originally Posted by Apollo

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.

[roondar]

Originally Posted by nandius_c

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

[nandius_c]

Originally Posted by roondar

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.

[S0ulA55a551n]

Think what payers want is pixel perfect collision detection with platforms and background etc but not with enemies

[nogginthenog]

Originally Posted by nandius_c

Personally, I don't like the idea of "wasting" Blitter DMA time for checking collisions

Does DMAF_BLTNZERO add any extra overheads? Just wondering.

[DanScott]

Always used bounding box to bounding box collision checks in my games

[nandius_c]

Originally Posted by nogginthenog

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]

Originally Posted by DanScott

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!

[saimon69]

Originally Posted by DanScott

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

[Photon]

Originally Posted by nogginthenog

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

[nandius_c]

Originally Posted by Photon

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 .

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?

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.

/rant This makes me want to code another game!! Argh

Which game did you code? I'd like to see that!

Thank you, sensei!

[invent]

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

[DanScott]

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

[nandius_c]

Originally Posted by invent

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?

[invent]

Hi nandius_c,

Thanks, the graphics are from this game

[Retro1234]

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?