Testing sprite collision

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
PeacefulKiller
Posts: 3
Joined: Fri Jan 04, 2008 5:28 pm

Testing sprite collision

Post by PeacefulKiller » Fri Jan 04, 2008 5:41 pm

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.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Fri Jan 04, 2008 5:52 pm

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.

PeacefulKiller
Posts: 3
Joined: Fri Jan 04, 2008 5:28 pm

Post by PeacefulKiller » Fri Jan 04, 2008 5:59 pm

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

thanks, again

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sat Jan 05, 2008 2:50 am

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.

PeacefulKiller
Posts: 3
Joined: Fri Jan 04, 2008 5:28 pm

Post by PeacefulKiller » Sat Jan 05, 2008 4:28 am

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 :)

Post Reply