[Jinroh]

On the GBA and Game Gear you must write your own collision detection routines to handle hardware sprites v. hardware sprites or hardware sprites v. tiles.

I can't think of many systems that have hardware collision and I'm pretty sure the NES is the same way. ^^
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.

[tcaudilllg]

I believe the Intellivision had such a function. It was tile-based -- if you nicked the corner of the sprite box, you scored a hit even without hitting the visible part of the image. Very useful for tile-based games; not so much for pixel-based games because, of course, it tends to thwart strategies that exploit the apparent "physicality" of the game world: that fireball which you thought would (barely) pass harmlessly overhead instead triggers the demise of your character!

But for a game like Tower of Druaga or Pac Man, where all movement is square-by-square, such a function would be all that was required, from a programming perspective, to make the game.

[Jinroh]

IIRC the also Atari 2600 has a hardware collision bit for it's player and missle graphics. However I cannot confirm 100% as I have a headache and it's been a while since I've done any 2600 coding.
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.

[tcaudilllg]

I remember reading about the Intellivision on romhacking.net. There is something about the complexity of collision detection that makes programming such systems distinctly unappealing to me. Automated collision flagging is, in my opinion, a defining characteristic of decent game engines.

[tcaudilllg]

I'll have to do some research before taking this thread any further.