Collision issue with solid elements

RadJunk

Administrator
Staff member
Yep, this is a problem with the default collision checker. Think about what is happening. The default collision detection is checking the *corners*. So...here's what is happening...the * are your collision points.

* *
____
| |
____

* *

There is no registered collision. This comes down to design. Make obstacles two high to avoid this problem. Or, make your bounding box < 16 pixels so that it can't happen. Or, use/write an alternative collision detection system that checks more than 4 points (or handles collisions in some other way). I tend to think of tall, thin characters like this as virtually 2.5d, and really make just the bottom parts of them collision points. Then they "walk in front of" each other and backgrounds too, which feels more natural.
 

RadJunk

Administrator
Staff member
Like in this attachment image. That's how I would handle a tall character like this. At least for now.
 

Attachments

  • Player Animation Info copy.png
    Player Animation Info copy.png
    28.5 KB · Views: 3,320

dale_coop

Moderator
Staff member
Ok, I understand. Thank you, Joe, for this explanation.
I will change the bounding box as you suggested, for now...
 

RadJunk

Administrator
Staff member
Yeah trust me, for tall characters it makes a lot more sense. Even Link's bounding box in the original Zelda wasn't all the way to the top of his head, which is why he walks against walls and looks like he's "in front of them slightly" and whatnot.
 

dale_coop

Moderator
Staff member
How do NesMaker check the collision between the Player and the Tile ?
For example the left collision, do you check if the player.topleft player point is between tile.topleft and tile.bottomleft
and same with player.bottomleft ? 2 points of collision ?
Maybe another way would be to check if player.topleft is < tile.bottomleft and player.bottomleft > tile.topleft ?

Sorry I can't make it yet in ASM

(I deal with that kind of collisions everyday with dates and periods of dates... at my job)
 

RadJunk

Administrator
Staff member
Yes, there are certainly other ways to handle it for different types of collision checking. Right now, we check all points against the potential point's collision type, and then react accordingly. It's certainly not the ONLY way to do collisions, but it's our vanilla solution. I'd imagine within a year, there will be alternative collision detection routines to pull in.

For instance, when we redux Troll Burner (a large character in a platformer), we will have the problem you describe, and we'll find creative ways to solve it. And then that becomes an alternate collision routine you'll be able to pull in to your physics design area of the tool (where you define things like movement and collision codes and whatnot). Other people might have even better or more efficient solutions you can pull in and compile with. These are the things that excite me about what this tool will be able to do :)
 

dale_coop

Moderator
Staff member
Yeah, right, it will be very fun, to add/change/try a lot of things in the tool. It's very well made for that, very versatile.
Again, congrats and thank you, Joe, for NESMaker :)
 

Mihoshi20

Member
dale_coop said:
Yeah, right, it will be very fun, to add/change/try a lot of things in the tool. It's very well made for that, very versatile.
Again, congrats and thank you, Joe, for NESMaker :)

Here here as I'll second that as I've learned more from NESmaker about how the NES actually works in the short time it's been out then a couple years of pouring over technical documents, walls of text, and the minuscule amounts of convoluted 'tutorials' out there.
 
Top Bottom