Testing sprite collision

Testing sprite collision
by PeacefulKiller on 2008-01-04 (#30053)

Hi, I'm a profissional developer, I've developed in lots of languages (C, C++, C#, Pascal, Basic, several flavours of Assembly, etc) and for different platforms.
However, I am new to snes development.
I had a Super Nintendo when I was younger and always wanted to try to build a simple game for this console (even if it is just emulated).
I've been reading docs and programming in the last few days.
I've learned the basic stuff, but there's one thing I couldn't find anywhere. How can you test if 2 sprites are colliding with each other (overlapping) or test if a sprite is colliding with a background tile? This is also basic stuff for a "simple" game.
I've searched several forums and documents and source code and couldn't find anything. In fact I noticed there's not a whole lot of documentation about SNES dev as opposed to NES dev, for example.

So if anyone could give me some pointers in this matter, I would really appreciate it, or simply tell me where I can look for an answer. My guess is there's a "trick" to do this, some register or something...but I really don't know.

Thanks in advance.

by Disch on 2008-01-04 (#30054)

No special SNES-specific trick. No register. Collisions must all be done with software. You check sprite collisions just as you would in a language like C or any other language -- you keep variables indicating the sprite's position and compare it to other sprites' positions. For BG collisions you'll need to have some form of level data in RAM (or ROM) that you can access to see if the sprite is colliding.

Collisions are not done by the SNES. Nor do they have anything to do with the graphics as they appear on screen.

As far as technical documentation goes -- Anomie's docs are spectacular. I was able to build a SNES emu from the ground up with them alone. You can find them here.

by PeacefulKiller on 2008-01-04 (#30055)

thanks, I was afraid of that
What that means is that there is no pixel-based collision test, just simple AABB collision-tests for obvious reasons...

thanks, again

by blargg on 2008-01-05 (#30062)

For an advanced system like the SNES, pixel-based collisions wouldn't cover the richness of what is graphically possible. Tile layers can appear in front of sprites, and games often have hidden obstacles with no graphical distinction, like the trunk of a tree below its foliage or a maze under a roof. Collision detection isn't very costly, so hardware assist doesn't buy much, and even when a collision is known, the particular direction must be determined anyway via bounding boxes and player velocity.

by PeacefulKiller on 2008-01-05 (#30065)

I understand, I was thinking of games like Street Fighter, for example, where I'm guessing now there must be several bounding boxes for attack areas (fists and feet) and target areas (such as torsos and heads) and of course no pixel collision detection.

Thanks for answering so fast, I tought it was gonna take a whie till I got some response, I guess SNES dev is still very much alive