In LBZ act 2, there are convex 90 degree curves that Sonic can run on -- and when he does, it seems impossible for him to run "too fast" so that he slips off, he always runs around the perimeter even with maximum possible ground speed. In my own tests re-implementing this same curve, I was unable to prevent him from running so fast that he "flies off" the top and becomes airborne instead of sticking to the surface (specifically with the movement "pop" described in the physics guide where his feet sensors rotate from right-wall mode to ground mode combined with high velocity). Given that when his sensors rotate from wall-mode to ground-mode, his rightmost floor sensor moves 10 pixels (radius of 19 -> radius of 9), and at ground speed of 16 on a 45 degree angle his x position ought to move ~7-8 pixels, then in total the "pop" should be able to move his floor sensor 17-18 pixels, possibly bypassing an entire tile's worth of collision. This is exactly what I am experiencing in my own recreation of the game and the cause of his "flying off the edge" behavior. Despite this analysis, that is not what actually happens in the game, so I analyzed what does, frame-by-frame, after hitting a red spring and was surprised to see this: The position and angle of his sprite show that he has a significant downwards angle, but the position of the very bottom of his feet show that the sensors must be colliding with a 45 degree or even shallower tile. What is the game doing here -- how can Sonic be moving at a near straight-downwards angle while also colliding with a tile that has a visibly much shallower angle? Is there some magic here that is the secret behind him not flying off of these ledges?
Upon further inspection, it is likely that he actually did collide with a downwards-sloped tile, which updated his sprite rotation without "snapping" to the ground again since collision had already occurred. I drew where his sensors would be assuming this to be the case, and it lines up exactly with this hypothesis: That being said, with the issue of the sprite being solved, this does not explain why he is able to maintain continuous contact with the ground despite his sensors potentially moving 17-18 pixels horizontally in a single frame.
In the original games, a sensor is really just a dot that is located at the bottom of Sonic's feet, and if it doesn't find a block, it'll search again 16 pixels towards the direction that it's facing. If it doesn't find one then, then it gives up. If you want to keep it visualized as a line, you can still just view it as a 17 pixel high line placed at the bottom of Sonic's feet. The block closest to the root of the sensor is chosen for collision and it lines Sonic up to where the root of the sensor it placed at the top of the block pixel column found. Here's a quick visualization of all that I mentioned: The green area segments are what really check for collision, and the orange segments just illustrating the positioning of the sensors. The highlighted dots are really the points where it's checking for block collision in the original games, with the purple ones being the ones that found a block. With your thing, it'd be more like: Or with the sensors rotated ala wall mode:
In addition to the sensor's vast reach, Sonic will accept & stick to floors of higher distances from his feet as he speeds up (up to 14px away in S2 I believe, most likely the same in 3) which helps him remain glued to the floor even if it's 14px "above" it after moving that frame. There has to be some form of distance limit check in place because if the sensors find nothing they return the distance from the sensor to the end of the second tile checked, so any distance of 16 and over is potentially nothing.
Yup. In Sonic 2 and 3, said threshold is the absolute value of his speed (X speed if in floor/ceiling mode, Y speed if in wall mode) + 4, capped at 14. It does this after picking the sensor that has chosen the closest block to Sonic. In Sonic 1, the threshold is always 14 pixels, no matter the speed. The only exception to this is if Sonic is rolling around those floating spinning discs like you see in Scrap Brain or Carnival Night. The check gets nullified/skipped and Sonic is forced to align with the disc, which is what keeps Sonic from falling off them. Also of note, if it detects that Sonic has moved inside a block, the max distance between the bottom of his feet and the top of the found block column he's in is 14 pixels in all the Genesis games. Any deeper in than that, and the collision is ignored. I believe that this exists to prevent issues with wall collision. At the end of the day, the collision basically works by detecting how far away/how deep inside Sonic's feet are in a block, and the sensors help out with finding said distance.
That makes sense, but I am referring to an edge case (haha) where your foot sensor moves 16+ pixels horizontally and then faces downwards, making it completely skip sticking to a tile. I made a gif here explaining my hypothesis (with a ground speed of ~10, I didnt keep track of subpixels but I believe this should be a good demonstration of what I am talking about) Link for if the gif isn't working: https://i.imgur.com/Xn28hao.gif The critical part here which the game in actuality seems to avoid, is the case where Sonic is in right-wall mode and lands on the very edge of the 45 degree tile. Then, he enters regular-floor mode *and* slides along the 45 degree incline, which looks like it can entirely bypass the tiles below him and make him go airborne.
This reminds me when I was trying the Sonic Worlds engine, approached very slowly to a similar curve to see if Sonic would fall, and not only he got glued to the ground, but gravity gave him speed and he didn't just run on the wall first, but on the ceiling next because there were more of those curves to put him upside down but running fast without input. It honestly makes sense if Sonic actually doesn't stay on that curved floor.
I did some tests via forcing Sonic's Ground Speed and Sonic can indeed just fall off running at 10px per frame. Depends on where he starts though, doesn't always happen. Normal running speed of 6px per frame is much more stable. Doesn't fall off when rolling (not once in my tests) however, most likely because the sensors don't travel as far when rotating, due to the smaller size.
Oh interesting, thank you. So there is no strange trickery going on here that makes him stay stuck to these curves, it's just that the conditions where he would fall off are extremely hard to encounter in regular gameplay. Thanks for your insight!
