Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Super Mario World hacking: labmaster | 3 guests
Acmlm's Board - I2 Archive - Super Mario World hacking - Collision Detection
  
User name:
Password:
Reply:
 

UserPost
Sukasa
Posts: 566/1981
They still have the box-shaped collision perimeter, just their ASM deals with it instead.
francoispress
Posts: 23/30
Originally posted by Darkflight
actually, if you look very closely, mario overlaps all other objects and spries by one pixel before he interacts with them.


Hmm... but how does one deal with the collision detection between sprites that are not box-like. You know, bubbles. How are their collision detection mapped? Is it safe to say that the bounding box would be completely inside the bubble?
Sukasa
Posts: 559/1981
actually, if you look very closely, mario overlaps all other objects and spries by one pixel before he interacts with them.
francoispress
Posts: 14/30
Originally posted by BMF3PO
The SNES does not have hardware collision detection, so it must instead utilize the screen location of each sprite. There's usually a "box" of coordinates programmed to match each sprite's size (though in SMW's case, each box is probably 16x16, aside from special sprites like Rexes and Dino-Rhinos), and if one sprite's collision box enters another's, the game runs an appropriate routine (hurt Mario, flip sprite, power-up, etc.).

For a good example of collision detection boxes, play Vectorman for the Genesis and press ABACAB while paused. The little lights that appear indicate where collision detection will occur.


So it's tile based just like I thought. Wouldn' that have and effect on the graphics? Oh, but wait... graphics are stored as tiles anyways. I'm wondering if these collision detections take into account transparent areas. And why does Mario or any of the other characters always hit platforms, ground, pipes, or walls perfectly? Why is there not overlap of the 2 sprites when the collision detection occurs? What would be your approach to this?
Sukasa
Posts: 556/1981
AFAIK It has not, although I would think that it wouild work something like the example below.

'get the sprite's size

(commented out becaue the code for the tables I was using was rather large)

'now check it with the player's X coordinate.

(the code is almost the same as the snippet below)

'Now, if the the X coords were reasonably close, check the Y co-ords

if Px > Ex then
if (px - Ex) < es AND (px - ex) < ps then coll = TRUE
else
if (ex - px < es AND (ex - px) < ps then coll = TRUE
End If

'now do the damage routine if there is a collision...
DisruptiveIdiot
Posts: 93/147
Originally posted by BMF3PO
The SNES does not have hardware collision detection, so it must instead utilize the screen location of each sprite. There's usually a "box" of coordinates programmed to match each sprite's size (though in SMW's case, each box is probably 16x16, aside from special sprites like Rexes and Dino-Rhinos), and if one sprite's collision box enters another's, the game runs an appropriate routine (hurt Mario, flip sprite, power-up, etc.).

For a good example of collision detection boxes, play Vectorman for the Genesis and press ABACAB while paused. The little lights that appear indicate where collision detection will occur.


How complicated is the collision code? Has it been mapped out fully yet? Just curious, I might have some ideas to fiddle with if they're feasible.
BMF98567
Posts: 869/1261
The SNES does not have hardware collision detection, so it must instead utilize the screen location of each sprite. There's usually a "box" of coordinates programmed to match each sprite's size (though in SMW's case, each box is probably 16x16, aside from special sprites like Rexes and Dino-Rhinos), and if one sprite's collision box enters another's, the game runs an appropriate routine (hurt Mario, flip sprite, power-up, etc.).

For a good example of collision detection boxes, play Vectorman for the Genesis and press ABACAB while paused. The little lights that appear indicate where collision detection will occur.
Juggling Joker
Posts: 837/1033
Yeah, I forgot Sprite to Sprite. Silly me. And I consider Mario a sprite, albeit a little more unique than the rest of the bunch.
Smallhacker
Posts: 1614/2273
Don't forget that (most) sprites turns around if it collides with another sprite. Also, don't forget Mario to sprite collision.
Juggling Joker
Posts: 832/1033
The only collisions that matter to the game is when a sprite touches a Layer 1 (or Layer 2, in some levels) object. Everything else is ignored, at least as far as I know.
francoispress
Posts: 6/30
Originally posted by Smallhacker
It's tile based when it comes to tiles and sprite based when it comes to sprites.


What would you concider tile based? Walls, blocks, ground, etc? I'm still confused.
Smallhacker
Posts: 1613/2273
It's tile based when it comes to tiles and sprite based when it comes to sprites.
francoispress
Posts: 3/30
How is collision detection done in Super Mario World? This has always intrigued me. Is it tile-based or sprite-based. Perhaps I will get into Super Mario World because it could attract more tourists to my site. It also looks like fun.
Acmlm's Board - I2 Archive - Super Mario World hacking - Collision Detection


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.032 seconds.