question about collision detection in classic "old" arcade shootemup games

General Discussions
#1

hey

I have been playing some arcade games lately in the mame emulator and I have noticed a detail in some of the arcade shootemup games,
example “Cyvern”. Its a game where you controle a dragon cyborg and the action in this game is just awesome. From the start theres tons of explotions
and the firepower is extreme. When i play these games i almost feel the power and destruction :slight_smile: ( cyvern is from 1998 so its not that old, and its a japanese game)

anyway… i have noticed in almost all of these arcade games when theres tons of bullets coming towards the player ship,not every bullet get you killed. I wonder if this is this coded so that not every bullet will hit the player or is it a glitch?

Since the screen is practically filled up with enemy bullets coming in the direction of the player ship at any moment in these games it would make it hard if every bullet would hit even if it looks like its going to hit. I guess the game looks more cool with tons of bulllets but it would be impossible to play if every bullet hit the players ship.

I am planning on making such an arcade game, for mobile phones, and I want to make it like these old type shootemups with tons of explotions etc… But how would I go about making the bullet system? Would you just skip collision detection on some bullets randomly?

#2

Eh… no. The player just has a tiny hitbox.

Some newer games allow you to enable a hitbox marker (eg hellsinker or perfect cherry blossoms [both pc]).

#3

What oNyx said. Rumour has it that the hit box in Ikaruga is only two pixels wide. :o The bullets also tend to have smaller hit boxes than the graphics would suggest. This is generally a good thing as you can throw lots of bullets against the player and they’ll tend to feel like they escaped by the skin of their teeth, rather than most western shooters where the overly accurate collision tends to make it seem unfair or unlucky.

#4

It’s interesting to note that computer technology has moved backwards in this area.

The Commodore 64, Atari 400/800 and other machines of the early 80’s had hardware that detected when any pixels of a sprite overlapped with another sprite or a foreground pixel.

The Amiga computer in the late 80’s early 90’s had the same feature in the hardware sprites and the custom blitter chip would do a similar detection when blitting with a bitmask.

So it used to be that pixel-perfect collisions were detected for “free” by the graphics hardware. Now we have to resort to clumsy and inaccurate hit boxes… though as Zulo mentioned they have some advantages.

#5

You could do that with occulsion queries, but you’d need a GF3 or later for that to work. :stuck_out_tongue:

#6

Its not really a technical issue. Its a design decision. Using a smaller hitbox allows way more bullets… not because you saved cpu time… instead its because you basically have then more space. The alternative solution would be useing a tiny player sprite. But that would be visually less pleasing… therefore there are tiny hitboxes.

#7

I don’t get it.

How does the size of the hit box have anything to do with the amount of bullets on the screen? You don’t care if the bullets overlap - right?

#8

Y’know… the player needs to be able to survive it.

A tiny sprite + ppcol OR a tiny hitbox… both allow more bullets on the screen.

Something like that+ppcol=instant death

(Never played a newer shoot em up?)

#9

That’s so true.

I’m still wondering how we could have such hardware pixel-perfect collision with OpenGL for example. Kev talked about it in another thread (he thought about stencil buffer etc), but unfortunately we didn’t find any solution so far.

#10

Two ways I could see:

With Occulsion Queries:

  1. Render sprite 1 into stencil buffer
  2. Render sprite 2 with drawing to only succeed on matching sprite 1’s stencil value
  3. Use occulsion query while rendering sprite 2 to see if any pixels get rendered (overlap!)

Without:

  1. Clear framebuffer to black
  2. Render sprite 1 into stencil buffer
  3. Render sprite 2 with drawing to only succeed on matching sprite 1’s stencil value. Set to draw white fragments.
  4. Grab rendered area and minimise down to a single pixel with auto mipmap generation
  5. Read back lowest mipmap’s pixel value. Anything > 0 is a collision.

Overall, painfully complex and its going to be rather slow as you have to read data the wrong way over the AGP bus. :stuck_out_tongue:

#11

Err… I never considered sloppy collision detection to be the solution to such things. Make each hit do less damage or something… It all depends on the situation though… the idea of a hit box makes sense when you don’t want some trivial pixels … like some silly antenna sticking out of your ship to cause the whole ship to explode when it is hit.

But, that looked like it was supposed to be instant death anyway :slight_smile:

#12

It’s not sloppy, just generous. And that wave is perfectly survivable (practically run of the mill for most good shooters).

Likewise the traditional bullet hell shooter is a one-hit-kills affair. Practically none of them actually have an ‘analog’ health bar, as it tends to detract from the fun of bullet dodging.

#13

tiny hitboxes for the player are the norm for the genre. It’s not too uncommon to have a single point for a hitbox. Getting to know your hitbox so you can weave through tight bullets is essential to mastering the game.

#14

This is the one I thought about, but reading back over the bus is just too annoying. Be nice to be able to do the comparison on the card so how :confused:

Kev