Fast (bounding box?) Collision detection

[Retro1234]

Say you used a grid like I said and I'm just thinking aloud the grid boxes are 8*8 1280 boxes now we know 2 objects are in a grid box but are they touching? do we really have to test all 4 corners? we know there exact position and there in a grid box and we know there size.

[zero]

Originally Posted by roondar

In order for the grid system to work, every object needs to know where in the grid it is. Setting aside the obvious problem of objects potentially falling into multiple grid coordinates (and yes, that even happens if the grid is huge and can cause issues if not accounted for), you still need to calculate which grid coordinate each object belongs too. This is not needed for bounding box collisions.

That cost is missing in your comparison.

Furthermore, most properly coded bounding box algorithms will exit as soon as possible. The version Northway shows is one of the exceptions here. Using a simple set of comparisons and exiting on the first 'fail' tends to have most objects leave the comparisons on the first or second test.

"Calculating" the grid coordinate is trivial. Simply discard the lowest 3 or 4 bits of the X and Y coordinates (depending on your grid size) and combine into a single word. There is some overhead but it only needs to be done once per object, not once per collision.

On an A1200 it's free because the limiting factor is memory bandwidth.

Obviously I was looking at worst case, not including early exit. Even with early exit it's still a lot worse than the grid system.

[zero]

Originally Posted by Photon

A grid is very special case. Furthermore, it must not round coordinates to the grid, or it will be more inaccurate even than mere box collision detection.

Have a look at the video I posted. It IS very inaccurate, but that's the trade-off that Konami made. It favours the player and the game is still a classic and immensely fun.

Very few games have perfect collision detection. Super Mario Bros only does collision detection every other frame, and even then it has a limit on the number of checks it can do so e.g. you can pass through some of Bowser's axes when speedrunning. PacMan famously allows you to go through ghosts under certain circumstances because of the grid collision system, which actually makes the game more exciting and fun.

What's more fun for the player, perfect collision detection or having 100 objects on screen?

[roondar]

Note: my post may have come across as if I was saying the grid system was as expensive as the bounding box system. This was not the intention. It is most likely faster in all but extremely unlikely cases. I was merely trying to point out there were more costs than you presented. Essentially, I felt you were making the grid system sound like it was better than it really is.

With that said, let's continue.

Originally Posted by zero

"Calculating" the grid coordinate is trivial. Simply discard the lowest 3 or 4 bits of the X and Y coordinates (depending on your grid size) and combine into a single word. There is some overhead but it only needs to be done once per object, not once per collision.

On a 68000 doing this is about as expensive as doing two parts of a standard collision check in a best case scenario. On a 68020 it's slightly better, but not by much. Which is not massively expensive, but for the number of objects you're talking about hardly 'nothing'.

On an A1200 it's free because the limiting factor is memory bandwidth.

No. Shifts are certainly not free on a 68020 and you're still writing some extra information into memory. Unless you want to do the grid determination on a per-check basis (which is not recommended as that'd be rather slow).

Obviously I was looking at worst case, not including early exit. Even with early exit it's still a lot worse than the grid system.

Best case bounding box with early exit does two memory reads and a compare per check. Best case grid does that as well, plus whatever overhead there is for determining grid coordinates. Worst case is a lot worse than that for bounding box though, so the grid based system is still going to win overall.

On the topic of what I want: more objects or better collisions, I'd say it all depends.

Bad collision detection can make or break games and I'm sure I'd be unhappy if my bullets regularly passed through enemies or if I got hit by something that wasn't actually touching me. You point out Gradius as an example. I've actually noted that the collision detection is inaccurate on that game (getting a modded TurboGrafx-16 that can play all the JP games as well is one of my better retro-themed decisions) and it did diminish my enjoyment somewhat - the game became less trustworthy because of it.

I guess that it's rather personal then.

[zero]

I meant you can pipeline the generation of the grid address on an A1200... Although I'm starting to wonder if I was right, I forgot there is no swap.w op-code.

But actually there is a better way to do it that I thought of. You have to calculate basically the same thing for the blitter anyway. It needs a memory address, i.e. a 16 pixel block aligned address. So you have done a lot of the work already.

I'm wondering if with clever alignment of the screen bitplanes you could optimize it even further.

In Gradius the collision detection for the player's ship favours the player. You never die when a bullet definitely didn't touch you. Sometimes you can survive when a bullet grazes the ship. That became a standard feature of Japanese shumups, with the player having a tiny hit box way smaller that the ship sprite.

If you require pixel perfect collision detection to "trust" a game then you must not trust very many games. Almost no classic 2D games have perfect detection.

[roondar]

Originally Posted by zero

I meant you can pipeline the generation of the grid address on an A1200... Although I'm starting to wonder if I was right, I forgot there is no swap.w op-code.

If you're referring to the 68020 concurrency features, they're relatively limited in capabilities. It's true that stuff in the cache can execute while the bus is busy, but only up until the result of any memory access is needed by the CPU and it still will take time to execute code in the cache - though using fewer cycles than it normally would (notably, it is possible for some instructions to be 'free', but this is a fairly rare occurrence).

But actually there is a better way to do it that I thought of. You have to calculate basically the same thing for the blitter anyway. It needs a memory address, i.e. a 16 pixel block aligned address. So you have done a lot of the work already.

You don't really calculate the same. The grid is basically two shifts, one 'and' and an 'or' (plus storing the result). The Blitter is basically one multiply, one shift and an add (plus the BLTCON and register stuff). I do agree that you can use the result of that one shift if the grid happens to be 8 pixels wide to get the X part of the grid coordinate without further calculation, though. That said, most optimised Blitter routines use a fair amount of registers so it remains to be seen if it's possible to actually integrate this without needing more memory accesses than just doing it separately.

Trying to do this while setting up blits is not a bad idea per se. I'm just not so sure it really fits as well as you think. Then again, I'm always open to new ideas so if you have a better one than I did - I'm all ears.

I'm wondering if with clever alignment of the screen bitplanes you could optimize it even further.

I don't see it myself, but perhaps it is possible. What do you have in mind?

In Gradius the collision detection for the player's ship favours the player. You never die when a bullet definitely didn't touch you. Sometimes you can survive when a bullet grazes the ship. That became a standard feature of Japanese shumups, with the player having a tiny hit box way smaller that the ship sprite.

I'll grant you that usually, the collision detection in Gradius (PCE) seems to work just fine.

However, at times it really did feel rather arbitrary. Some bullets would graze me without registering a hit, others would seemingly graze no 'deeper', but would kill me. This is a consequence of a grid based system. It's inaccurate, which leads to similar situations not resulting in the same outcome.

Don't get me wrong, the game is rather enjoyable. But when compared to other games in the genre, the collision detection is just not as good and this does sometimes make it less fun or more frustrating to play.

Note that this is completely separate from the small hitboxes used in shoot em ups. That feature was not inspired by Gradius and it's grid system. It came into being when bullet/enemy counts went up in games and was put in to keep games playable and as a bonus, added the thrill of a near miss.

If you require pixel perfect collision detection to "trust" a game then you must not trust very many games. Almost no classic 2D games have perfect detection.

I don't require pixel perfect collision detection. I generally only require consistent collision detection. And many games have that. Sure, they very occasionally might glitch (see Super Mario Brothers), but by and large you know what will happen and when.

A grid system can't do easily this, because it's detected collisions change based on completely arbitrary factors.

You've mentioned Pacman here and it is one of the few games that truly use a grid system well. It works so well because its map is highly structured and movement is restricted. This means that a checks can be done using a grid and still be fairly accurate. It's also a game where the player does not have weapons which further limits the amount of 'perceived weirdness'.

Again, I'm not saying a grid based system definitely is a bad idea or that it can't work. I'm merely trying to point out that it has pros and cons and that both of these are relevant, not just the pros. Note that this goes for all types of collision detection, not just grid systems.

[zero]

Originally Posted by roondar

If you're referring to the 68020 concurrency features, they're relatively limited in capabilities. It's true that stuff in the cache can execute while the bus is busy, but only up until the result of any memory access is needed by the CPU and it still will take time to execute code in the cache - though using fewer cycles than it normally would (notably, it is possible for some instructions to be 'free', but this is a fairly rare occurrence).

Yes, that's what pipelining refers to. You need to arrange the memory accesses so that they happen when the bus is available and use the cycles in-between for other stuff.

You don't really calculate the same. The grid is basically two shifts, one 'and' and an 'or' (plus storing the result). The Blitter is basically one multiply, one shift and an add (plus the BLTCON and register stuff).

Remember that the 020 can do shifts of any length in the same minimal (4) clock cycles if executing from cache.

You will probably want your bitplanes to be at least double the screen width to assist with scrolling. You could go to 1024 pixels wide and use shifting instead of a multiply instruction. There is no wasted memory as you can use the extra space for storing other data.

Since you are limited by memory/chipset bandwidth the extra stuff you need to do to create the grid address is basically free, as in you can still hit every single available bus access. The only additional overhead is a single 16 bit write to store the result.

I don't require pixel perfect collision detection. I generally only require consistent collision detection. And many games have that. Sure, they very occasionally might glitch (see Super Mario Brothers), but by and large you know what will happen and when.

Super Mario Bros is famous for it's inconsistent collision detection.

For example, collisions with enemies are only done every other frame. So when you jump on an enemy it's essentially random how far down you will have moved before hitting it, and thus the height of the resulting bounce is also random.

Another famous example is at the end where Bowser throws axes at you, and it's possible to jump through one of them because the game can't check collision on all of them in one frame. so you actually have a window of 3 frames where that axe can't kill you.

You've mentioned Pacman here and it is one of the few games that truly use a grid system well. It works so well because its map is highly structured and movement is restricted. This means that a checks can be done using a grid and still be fairly accurate. It's also a game where the player does not have weapons which further limits the amount of 'perceived weirdness'.

But again, Pacman is infamous for having very inaccurate and inconsistent collision detection.

The ghosts can get right on top of the player, clearly touching, and the player doesn't die. It depends on the exact timing of when the player leaves an grid square and when the ghost enters it, so it's essentially random. It's so janky you can actually pass right through ghosts by running at them sometimes, as Pacman and the ghost exchange grid squares in the same frame.

By most estimates that just makes the game more exciting. You never feel cheated because it favours the player and when you die you can be sure the ghost was on top of you, but it also allows for some element of chance and extremely close calls.

[roondar]

Originally Posted by zero

Yes, that's what pipelining refers to. You need to arrange the memory accesses so that they happen when the bus is available and use the cycles in-between for other stuff.

Right. Problem being this is really rather hard to keep up. Most of the time, you either have more memory accesses than other instructions or the other way around and thus, the benefits from this interleaving are usually limited.

Remember that the 020 can do shifts of any length in the same minimal (4) clock cycles if executing from cache.
...
Since you are limited by memory/chipset bandwidth the extra stuff you need to do to create the grid address is basically free, as in you can still hit every single available bus access. The only additional overhead is a single 16 bit write to store the result.

Yes, 4 cycles per shift (assuming LSL/LSR and no more than 8 bits). So two shifts, an 'and' and an 'or' will cause you to 'miss' up to 1.5 memory cycles. I simply do not agree with calling it 'free'. It absolutely isn't free. Code in the cache does take time to complete. It can and will cause you to miss memory slots. I do agree it is cheap, but cheap and free are two very different things.

As for the 68020 in general: I'm not sure sure it is really all that relevant. On an A1200, the CPU is fast enough to do plenty of collision checking as is. This stuff is far more relevant when looking at the A500/68000, where the CPU sometimes struggles to keep up.

Super Mario Bros is famous for it's inconsistent collision detection.

No it isn't

This really is the first time I've heard anyone call it inconsistent. What I've seen and heard so far makes it out to be consistent, but with some well known glitches (that can be abused by speed runners).

For example, collisions with enemies are only done every other frame. So when you jump on an enemy it's essentially random how far down you will have moved before hitting it, and thus the height of the resulting bounce is also random.

IMHO, doing collisions every other frame is a far more consistent way of doing them than basing it on something as unpredictable as object X&Y mapped to a grid. It seems to me that this is partly why Super Mario Brother collision detection feels good and not really arbitrary in the general case.

The point with Super Mario Brothers is that these glitches are extremely rare in normal game play (unless sought after and abused). This is contrary to grid based systems where glitches are both far more more common and less predictable.

But again, Pacman is infamous for having very inaccurate and inconsistent collision detection.

The ghosts can get right on top of the player, clearly touching, and the player doesn't die. It depends on the exact timing of when the player leaves an grid square and when the ghost enters it, so it's essentially random. It's so janky you can actually pass right through ghosts by running at them sometimes, as Pacman and the ghost exchange grid squares in the same frame.

Yes, the grid shows off it's weakness when this happens. Whether or not this is good depends on your situation. If this happens just after you had picked up a short duration power pill, I'm sure it would not be 'exiting', but rather 'annoying'. Again, not something to try and achieve.

By most estimates that just makes the game more exciting. You never feel cheated because it favours the player and when you die you can be sure the ghost was on top of you, but it also allows for some element of chance and extremely close calls.

There's two reasons why you don't feel cheated in Pacman. The first is that you're not trying to shoot the ghosts and see half your shots fly straight through them. The second is that you can always enter part of a ghost - not just occasionally. They made the grid very small compared to the player/ghosts. So small it's impossible to die when 'just' touching a ghost. The result is that it feels deliberate that you can partly touch a ghost. The same doesn't go for Gradius as the bullets are rather small themselves. Which makes it feel a lot more random.

Essentially, the makers of Pacman took their poor collision detection and made it a gameplay feature. This clearly doesn't always work and poor collision detection certainly doesn't make games more 'exiting' in the general case.

All this just means you need to be aware of the flaws if you decide to go the grid/half frame route and handle them as well as you can.

[Photon]

Originally Posted by zero

Have a look at the video I posted. It IS very inaccurate, but that's the trade-off that Konami made. It favours the player and the game is still a classic and immensely fun.

Very few games have perfect collision detection. Super Mario Bros only does collision detection every other frame, and even then it has a limit on the number of checks it can do so e.g. you can pass through some of Bowser's axes when speedrunning. PacMan famously allows you to go through ghosts under certain circumstances because of the grid collision system, which actually makes the game more exciting and fun.

What's more fun for the player, perfect collision detection or having 100 objects on screen?

If your question is a general one, and you just want an opinion, I think avoiding frustration makes a game more fun. I'm not sure what having 100 objects on the screen for the sake of it adds to gameplay fun?

You exaggerate to make your view seem strong. Amiga 500 and NES are unable to support 100 collidable objects on screen without an FPS so low that it ruins (action) gameplay.

I can think of only one game type that needs so many: Jap bullet hell shooters. Most of the gameplay is reduced to sort of navigating a maze of holes between bullet streaks. In such a game it would be all the more important to have competent collision detection.

There's no "vs" here for me. I think every game should have competent collision detection, because it's likely the #1 cause of frustration in games, even modern ones. The best way is to plan it in even as you first write down the game idea, and think about it for each addition to the game, i.e. "Is this a collidable object? What should it collide with? Under what circumstances could detection fail?", because this will automatically reduce the number of tests as you know more about the objects and adjust them for better collision.

I think the devs who left shaky detection in were unable to bring the detection time down and succumbed to hacky solutions. If hacky solutions can be found that cut down on the number of accurate tests, they should be used - but not as the final test.

[zero]

Originally Posted by Photon

If your question is a general one, and you just want an opinion, I think avoiding frustration makes a game more fun. I'm not sure what having 100 objects on the screen for the sake of it adds to gameplay fun?

It looks visually impressive, and the player enjoys having a huge amount of firepower at their disposal, and feels skillful at avoiding a screen full of bullets and enemies.

Really hardware was the limiting factor until the late 90s, when we started to see real "bullet hell" games. There are interviews with the developers if you are interested, but basically they had known for a long time that players wanted more moving objects, more animation and excitement, and were really just seeing how far they could take it.

It also gives designers more options. With only a few small enemies and bullets on screen they have to find other ways to make the game hard, like having narrow tunnels or really fast movement. Stuff that feels cheap and unfair.

You exaggerate to make your view seem strong. Amiga 500 and NES are unable to support 100 collidable objects on screen without an FPS so low that it ruins (action) gameplay.

True, but Gradius is on a 16 bit system (actually an 8 bit CPU and 16 bit VDP) and has many, many objects on screen. It has lots of hardware sprites of course. It's interesting because the limitation is not the number of sprites it can display like on the Amiga where the blitter is not nearly as capable, but rather the CPU's ability to run the game logic. Hence the need for a very high performance hit detection system.

That's why I mentioned it, it's a great example of this technique.

I think every game should have competent collision detection, because it's likely the #1 cause of frustration in games, even modern ones.

I agree, we just disagree on the definition of "competent". For me it depends on the game; Pacman would be less fun if it were pixel-perfect.

[Photon]

Originally Posted by zero

It looks visually impressive, and the player enjoys having a huge amount of firepower at their disposal, and feels skillful at avoiding a screen full of bullets and enemies.

Really hardware was the limiting factor until the late 90s, when we started to see real "bullet hell" games. There are interviews with the developers if you are interested, but basically they had known for a long time that players wanted more moving objects, more animation and excitement, and were really just seeing how far they could take it.

It also gives designers more options. With only a few small enemies and bullets on screen they have to find other ways to make the game hard, like having narrow tunnels or really fast movement. Stuff that feels cheap and unfair.



True, but Gradius is on a 16 bit system (actually an 8 bit CPU and 16 bit VDP) and has many, many objects on screen. It has lots of hardware sprites of course. It's interesting because the limitation is not the number of sprites it can display like on the Amiga where the blitter is not nearly as capable, but rather the CPU's ability to run the game logic. Hence the need for a very high performance hit detection system.

That's why I mentioned it, it's a great example of this technique.



I agree, we just disagree on the definition of "competent". For me it depends on the game; Pacman would be less fun if it were pixel-perfect.

Pacman would not be less fun if you collided when you collided. What kind of nonsense is this?

Competent simply means not missing collisions that you have decided should be checked (or are explicitly expected, like falling onto a solid surface and stopping). Glitched shortcuts or falling through the ground are examples of game designs where collision was an afterthought (at least if they can be achieved without specifically grinding for niche exploits like speedrunners do).

Bullet hell is basic and represents a lack of innovation, not innovation. All games including basic ones got hardware upgrades. (And failed or succeeded in exciting the player.)

Gradius has nowhere near 100 collidables on screen either. The fact that collision works with flickering sprites at all (is flicker also OK in a game, according to you?) is probably the reason why all enemy collidables move so slowly in it. Yes, you can distribute collision detection over frames if you adjust the speed according to the speed calculation at the bottom. (But the hand-eye coordination loop will be broken; they will happen a few frames later, where as a timely detection would have let you make decisions.)

Difficulty levels are implemented in arcade action games by skilled programmers writing perfect AI (which is easy) and then degrading it to human levels - in an interesting and/or semi-realistic way (this is the hard part).

What would make a shooter more fun than "let's add moar bullets" is designing interesting enemies.

I'm sure they could have made a BH shooter performant enough without the dedicated collision hardware and still keep the cheap, slow CPU (c) - provided the collision detection was hacky enough, of course.

But the question is: Would anyone have played such a game and not hated its guts?

Unfair, you say. A collision that you check for but miss because you don't care is the definition of unfair, and frustrated gamers worldwide agree (the reason being that they can adjust nothing in their gameplay to combat it).

[NorthWay]

Originally Posted by NorthWay

Can't you do bounding box with min(abs(x-x_box),abs(y-y_box)) < (radius+box_radius)

BTW, this should also be possible to shuffle the logic on so you have an early exit if either is bigger than the added radius.
And you can do a branch-free ABS() in something like 3 instructions, though that might be 2 cycles slower on 68000.

[zero]

Originally Posted by Photon

Pacman would not be less fun if you collided when you collided. What kind of nonsense is this?

I guess you haven't played the original arcade version much. I own an original board, BTW.

The game is played out in a claustrophobic little maze and the ghosts are often right on your tail. Particularly when it comes to corners they get very close because the gap temporarily narrows as you change direction.

If collision detection was pixel perfect they would have had to adjust the movement of the ghosts to make the game easier. It would just have been way too hard and unforgiving. Hit boxes might have worked but would have had to have been fairly small.

You are talking about a game that is a certified classic, one which was so popular the Japanese government had to mint more 100 yen coins because of it.

Bullet hell is basic and represents a lack of innovation, not innovation.

I see you aren't a fan of the genera. If you can get a copy of the Ikaruga Appreciate DVD, or even just watch some of the top players on YouTube, you might understand.

Gradius has nowhere near 100 collidables on screen either.

Never claimed it was. Read more carefully.

The fact that collision works with flickering sprites at all (is flicker also OK in a game, according to you?)

In Gradius on the PC Engine it is. It's been done such that it affects the player's shots and large boss enemies rather than stuff that is a direct threat to the player. Obviously it's not ideal but given the limitations of the hardware it's an acceptable compromise.

What you would do? Make the enemies smaller or reduce the number of them to avoid flicker? Take away the laser weapon and replace it with something less fun because it flickers now and then?

Difficulty levels are implemented in arcade action games by skilled programmers writing perfect AI (which is easy) and then degrading it to human levels - in an interesting and/or semi-realistic way (this is the hard part).

Not at all. In fact most Japanese shooters have very simple AI, that isn't really AI in any sense. Again, check out Ikaruga for the absolute pinnacle of the genera, but generally any patterns and movement logic are designed for a specific purpose. Somewhat predictable behaviour is preferred so that players can learn the game rather than always just reacting to it.

Unfair, you say. A collision that you check for but miss because you don't care is the definition of unfair

People are very tolerant of "unfair" misses if it's in their favour. Nobody ever threw down their controller in disgust because they didn't die.

[touko]

I hope you do not link sprites flickering in gradius PCE, with the CPU power, because is not related.

[Shatterhand]

You guys really should be there when we were playing Zanac and everything was flickering as fuck and we were all like "OH MY GOD THIS IS THE BEST GAME EVER".

If Amiga games had flickering like NES games do but they were actually AS GOOD as some NES games are, I'd be perfectly fine with it.

When I became a coder and learned how things worked, I begun noticing flickering a lot more. When I just played the damn games, for me it was like "HOLY CRAP THE GAME IS PUSHING EVERYTHING THIS MACHINE CAN DO THIS IS AWESOME!"


Now I really wonder how Bullet Hell is "Lack of Innovation". I've been a shoot'em up player since.... ever basically. I've been looking at the genre for years... no, shit, decades. I was there when Batsugun was released (Well, at least the home version, never saw an arcade of it around here) and everyone was "Holy shit that's a shitload of bullets on screen, this is AWESOME". Bullet Hell was a natural step of the genre and it was done in many different ways... Look at Dodonpachi Dai-Ou-Jou, the Tohou games, Gigawing and Dragon Blaze, all of them are very different between them.

[rothers]

If you're in dual playfield I'd go with checking the pixels as you draw the bullets. That's how I always used to do it. Then only if there is a 'hit' work out what it has hit. This can also lead to pretty perfect detection. It would/could also cover the background being hit too.

[zero]

Originally Posted by Shatterhand

If Amiga games had flickering like NES games do but they were actually AS GOOD as some NES games are, I'd be perfectly fine with it.

I sometimes wonder if this was because a lot of Amiga users has monitors. The flicker was much more noticeable on a monitor than on a TV. I guess TVs were designed to make the image persist a bit more because they were mainly displaying interlaced video.

[Retro1234]

Flickering on the NES looks kind of cool on the Amiga not I can't explain it, I've also seen flickering on the Atari ST and it looked acceptable.

[roondar]

Originally Posted by Shatterhand

If Amiga games had flickering like NES games do but they were actually AS GOOD as some NES games are, I'd be perfectly fine with it.

There's actually Amiga games without flickering that are as good as some of the best NES games

Now I really wonder how Bullet Hell is "Lack of Innovation". I've been a shoot'em up player since.... ever basically. I've been looking at the genre for years... no, shit, decades. I was there when Batsugun was released (Well, at least the home version, never saw an arcade of it around here) and everyone was "Holy shit that's a shitload of bullets on screen, this is AWESOME". Bullet Hell was a natural step of the genre and it was done in many different ways... Look at Dodonpachi Dai-Ou-Jou, the Tohou games, Gigawing and Dragon Blaze, all of them are very different between them.

I concur, Bullet Hell can be quite innovative. That said, I think there's room for both. A good game does not need a gazillion objects to be fun.

[Shatterhand]

There's actually Amiga games without flickering that are as good as some of the best NES games

I've said this here once before, so I'll be repeating myself.

I love the Amiga. It's my favourite machine ever. I have fondly memories of it, from all my "retro toys" its the one I play the most, it's the machine I chose to code for nowadays etc, it was my gaming machine during my youth, and I always defend its library of games when, on retrocomputing fairs around here, I keep hearing "The Amiga is a great computer with only shit games on it" (Yeah, I hear this *a lot*).

But no. Super Mario Bros 3, Megaman 2, Ninja Gaiden, Shadow of the Ninja... the game that inspired my nickname (Shatterhand)...

The NES is full of brilliant 2D platform games that *no* Amiga game can even dream of touch. Everytime I'm playing with my NES I can't help think "Holy shit, this could be easily ported to Amiga and if it was done back at the time it would be a KILLER game on it".

And then you have the shoot'em ups... Zanac, Gunnac, Recca, Crisis Force, Gradius 2... again, nothing on Amiga can touch those gems in terms of pure gameplay quality.

I didn't have a NES back at the time, but owning one now and finally getting the gripes with its library, I really can understand why it was so damn popular. It really has a huge library of amazingly good games.

This doesn't mean the Amiga doesn't have great 2D action games. It does. But.... it's just too hard to compete with what the japanese devs were doing back at that time.

It's like has been said on another thread. I always felt european devs were too busy trying to push the hardware to its limits instead of designing games that were *really* good.

I concur, Bullet Hell can be quite innovative. That said, I think there's room for both. A good game does not need a gazillion objects to be fun.

If I didn't agree with you I wouldn't be trying to make an Amiga shoot'em up right now