[qrmn]

I used it. It's not as fast an approach as it sounds; you want to do hitbox collision first. But if there's a better way to really do pixel-perfect collision, I couldn't figure it out - maybe subdividing hitboxes would have been, but how does that work when the sprites change? I always thought of plain old hitboxes as being unnecessarily cruel - the player can't see them - but if you were on the NES, you probably wouldn't have CPU time for much of anything better.

Fortunately, I was on something less basic. Unfortunately, I was working on a bitplane mode (for my sins); the CPU didn't have a barrel shifter (so, for speed, one needed to store pre-shifted copies of sprites and masks); and, because the assembly instruction of course wants to modify the output, I ended up copying the dest mask and doing the source as self-modifying code with chains of unrolled andi.l #<character mask>,-(a0) / bne.w pairs; if the chain falls through, the player's just scraped by a mob.

This was of course back in the day that one didn't have to worry about pipeline or cache invalidation, because one simply didn't have the luxury of such things. The naïve loop/temp register implementation would be faster now (and, thanks to µcode and register renaming, would be what the CPU really does inside anyway).

Incidentally, you want to really look out for your animation code in games like this, because it impacts directly on game logic. Anything that might reset the animation counters will have side effects. I'm not sure if it was intended that Tiki - despite being a flightless kiwi - from Taito's The NewZealand Story actually can fly with repeated pushes of up mid-jump, for example (although the presence of secret level design elements catering for it suggests it may be, and could actually be a huge easter egg considering it wasn't documented!).

Similarly, Turrican II has a trick involving what happens if you fire and let off a smart bomb (space) at the same time while jumping, and then jump again - and I don't know if that's intended, but there's at least a couple of platforms with some nice goodies I don't think you can get to any other way.

[mrob]

IMO plain hitboxes are actually less cruel. Pixel perfect collision doesn't distinguish between solid parts of the object and things like cloth/hair/grass/feathers that would brush past without a real collision, or small loose items that would be knocked aside without the whole object catching. Hitboxes better represent these types of collisions, and you easily get a feel for where they are. Pixel perfect collision feels unfair when you collide on a single stray pixel.

[davedx]

> I'm not sure if it was intended that Tiki - despite being a flightless kiwi - from Taito's The NewZealand Story actually can fly with repeated pushes of up mid-jump, for example (although the presence of secret level design elements catering for it suggests it may be, and could actually be a huge easter egg considering it wasn't documented!).

Surely it was intentional. I remember very early in the game was a section where you fell just far enough to reverse your fall by rapidly tapping into flight (a very subtle tutorial), and several secret parts where a fall onto spikes could be turned into flight to a secret area.

IIRC, you could fly in the flying saucer too, but it was 2 tiles wide so many places could only be reached by flying "unassisted".

It's been a very long time since I played that game though! Arcades back in the 90s. Fantastic, difficult game.

[eru]

> I always thought of plain old hitboxes as being unnecessarily cruel - the player can't see them [...]

Err on the side of the player. Ie give the player sprite a little smaller hitbox than would be warranted by pixel perfect collision detection, and the enemy sprites a little bigger one. That will feel very fair, and you can ramp up the difficulty in other ways.

Following the same principle, Canabalt famously allows you to jump a little bit after you already left the rooftop.