Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.
They should start at his Y position and extend at least 16 pixels below his feet at ground level
Since the sensors stretch so far below his feet, what stops them from detecting the ground again in the step in which he jumps, never letting him leave the floor? Simple. He ignores them unless Ysp is 0 or greater, so he'll only detect the ground while moving down.
Does this mean, if you're falling, and you're less than a block above the ground, you'll actually snap to the platform?
Quietust wrote:Not sure how this is relevant to NESdev
It's a physics implementation question. We have tons of physics discussions here. The game from where a particular idea comes from shouldn't affect its relevance to NESdev'ing. I mean, this is very different from "How do I hack Sonic the Hedgehog?".
As for the actual question, I'm not 100% sure, but I believe Sonic has a "grounded" state, and only in that state he'll attach to the ground like this. I don't know what the deal is with that Y speed explanation, but I'd jump to the same conclusion as you from reading just that.
Since the sensors stretch so far below his feet, what stops them from detecting the ground again in the step in which he jumps, never letting him leave the floor? Simple. He ignores them unless Ysp is 0 or greater, so he'll only detect the ground while moving down.
Does this mean, if you're falling, and you're less than a block above the ground, you'll actually snap to the platform?
I have a hard time believing both of these statements.
When I implemented slopes it was absolutely necessary that slopes collide regardless of Yspeed. Here's an example that would break if you only check slopes when Yspeed > 0:
And snapping to slopes a block above is something you absolutely can't do because it looks like total shit. When I tried it, it was extremely obvious when the player would snap, so I really doubt that Sonic is doing this.
Yes, the problem is that it implies that Sonic will snap to the ground when gaming down, which is not true.
The Sonic Physics Guide is great, I couldn't possibly get all of that on my own just from looking at the disassembly, so I'm really thankful it exists, but being target to people who are recreating the physics in higher level languages, it sometimes comes up with needlessly complicated expressions to replicate behaviors that are dead simple and obvious in assembly. It also has these little pieces of "trivia" that seem pretty random. Has anyone really thought that the described vertical collision system could cause the player stick to the ground permanently? Even if they did, that explanation alone isn't enough to explain why that doesn't happen, since Sonic also doesn't snap to the ground when falling back down (at least not that I have noticed!), a time when his Y speed is greater than 0, so there's clearly something missing.
You missed this part, describing how the sensors work differently in air mode:
Sonic's A and B sensors are much the same in the air as they are on the ground. The difference is, when they detect a solid tile, Sonic isn't immediately set to the height found in the tile minus 20. Instead, he's only set to it if he's already lower than that height. Otherwise he'd suck to the floor when he got close to it.
There you go. In air mode, Sonic doesn't "pop" down, only up.