SPG:Solid Objects
From Sonic Retro
Notes:
- Research applies to all four of the Mega Drive games, and Sonic CD. If there are any varying differences between the games, this will be covered below.
- Variables and constants for Sonic and other characters such as X Position and acc will be referenced frequently, they can be found in Basics.
Contents
Introduction
There are many objects in Sonic games and they interact with Sonic in many different ways and are a very different beast than Solid Tiles. Object-player collision doesn't work the same way as Solid Tiles. This guide will go over the collision of various objects found in the Sonic trilogy.
Object Hitboxes
Objects such as rings, enemies, and bumpers have a hitbox, which is a general area that will trigger some kind of reaction with Sonic when both their hitboxes overlap. Object hitboxes are centered on the object's X and Y Positions.
Sometimes objects which seem solid (like bosses or bumpers) actually only have a hitbox, and when they overlap, simply push Sonic in the other direction. As a general rule, any seemingly solid object that Sonic cannot stand on is most likely actually using a hitbox rather than real solidity.
Hitbox Reaction
If Sonic's hitbox touches an object's hitbox, some kind of reaction will occur. Usually this is totally specific to the object, like collecting a ring or bursting a balloon. Though, the object can set specific flags which change the "type" of reaction they will have. The two most consistent reaction types are as follows:
Hurt Hitboxes
While these aren't solid, any contact with them will immediately give damage to Sonic. Examples are the spikes on the GHZ log bridge, the spikes under a MZ Spike Trap, and certain projectiles.
Badnik Hitboxes
These are very similar to hurt hitboxes, with the obvious difference being that while rolling, you won't take damage and will instead destroy the enemy.
Ahead, objects with hurt hitboxes will be coloured differently.
Sonic's Hitbox
In order to interact with other object's hitboxes, Sonic needs his own.
Sonic's hitbox is much like that of any other object. It sits at Sonic's X Position and Y Position. It has a width radius of 8, and its height radius is always 3 pixels shorter than Sonic's Height Radius, making it 17 X 33 pixels in size while standing.
When crouching, Sonic's hitbox needs to shrink. Problem is, Sonic's position and Height Radius don't actually change at all while crouching. So to tackle this it manually updates the hitbox's size and position while Sonic crouches, where 12px is added to the hitbox's Y position, and the hitbox's height radius is set to 10.
Quirks With Hitboxes
Because these hitboxes aren't even numbered in size, and because object origins don't lay perfectly centered between pixels (rather they are 1px left and down) most hitboxes will also appear 1px too big on the right side and the bottom side. This is simply how things work in-game and for that reason won't be ignored. Sprites like rings are even-numbered sizes (such as 16 X 16) so an anomaly like the following can (and does, always) occur.
Rings can be collected from one direction sooner than the other, you can try it yourself via debug mode. As long as the sprite of the ring is 4px out from the tiles on each side, you'll experience this inconsistency. A Ring's hitbox is defined as a radius of 6, but this results in a box with a width of 13 rather than 12. Because all sprites like this are an even size, but their hitbox must be odd, the box cannot be perfectly set on the sprite and will be larger to the left and bottom.
This is the case with any object's hitboxes.
The same is true for solid object boxes, so Sonic will push against objects 1px further away when facing leftwards than he will tiles.
Solid Objects
As stated above, object collision is totally separate from tile collision. Sonic does not collide with objects using his solid tile sensors, instead, special calculations are used to check if Sonic's general shape is inside an object's solid box, and push him out.
This all occurs after Sonic's code has been executed for that frame, including his tile collision and movement. Since objects run their code after Sonic, it's the job of the objects to push Sonic out of themselves.
Note: These collisions deal with floored positions (integer values), ignoring any fractional/subpixel amount.
General Solid Object Collision
Solid object collision does away entirely with hitboxes and instead uses the actual size of the objects. The Width Radius and Height Radius. For normal objects that is, Sonic will use his Height Radius for this too, but horizontally he of course needs to use his Push Radius instead.
The following is long. It is written in a way very close to how the original game has it coded because accuracy requires it. To orient yourself, a brief overview of the long process below goes as follows:
- Sonic will check if he is overlapping the object.
- Sonic will decide which side of the object he is nearest to n both axis (either left or right and either top or bottom).
- Then check how close in pixels he is to being outside of the object on that side (distance to left or right and distance to top or bottom).
- The game then decides whether he's closer to a horizontal side to be pushed out on the x axis or a vertical side to be pushed out on y axis.
- He will then be pushed out towards that side on that axis by the distance he overlaps.
Now, let's get into the details.
The first thing the object collision code does is check if Sonic is standing on the object (using a flag which is set if he lands on one). If he is, it will skip straight to checking if Sonic has walked off the edges rather than general object collision. Otherwise, it will continue as follows.
Checking For An Overlap
To check for an overlap the game needs to know the boundaries that Sonic's positions need to be within.
Horizontally, the object combines its own X radius with Sonic's Push Radius and adds 1px extra (so Push Radius + 1).
Vertically, it very similar. The object combines its own Y radius with Sonic's current Height Radius to get a combined radius. 1px isn't added here, but it is (kind of) later after a collision has occurred.
Note: Objects don't always use their real Y radius when acting solid, and will just pass in a hard-coded value. Sometimes this value is slightly different than you'd expect, like 17 instead of 16. Point being, it's worth checking each individual object for the specific values they use. Generally speaking, the above applies to most.
Here's a demonstration of how these new radiuses relate to Sonic's size (while standing in this case) for a block.
From this point, when I refer to the object's combined radiuses I will call them combined X radius and combined Y radius.
Now all the game needs to worry about is Sonic's X Position and Y Position being within this new box, it no longer needs to worry about what Sonic's sizes are.
Horizontal Overlap
The game will calculate the difference between Sonic's X Position and the object's left side.
left_difference = sonic's X Position - object's x position left_difference += combined_x_radius //add combined radius
Then, it will check if this new difference value has passed the boundaries, and exit the object collision if it has.
//sonic is too far to the left to be touching if (left_difference < 0) exit; object_x_diameter = combined_x_radius * 2 //get object's x diameter //sonic is too far to the right to be touching if (left_difference > object_x_diameter) exit;
If no exit occurred, Sonic is overlapping on the X axis, and it will continue. The game will remember this left difference.
Vertical Overlap
Then for vertical overlap, it calculates the difference between Sonic's Y Position and the object's top side.
top_difference = sonic's Y Position - object's y position top_difference += 4 //add 4 top_difference += combined_y_radius //add combined radius
The game also allows Sonic to be slightly above the object by 4 pixels and still overlap, extending the top of the object 4 pixels for extra overlap. This is likely just in case the object moves down slightly or the object is slightly lower than a previous ledge Sonic was standing on. The game does this by effectively pretending Sonic is 4px lower than he really is when checking the Y overlap. This is subtracted later.
Then, it will check if this new difference value has passed the boundaries, and exit the object collision if it has.
//sonic is too far above to be touching if (top_difference < 0) exit; object_y_diameter = combined_y_radius * 2 //get object's y diameter //sonic is too far down to be touching if (top_difference > object_y_diameter) exit;
If no exit occurred, Sonic is overlapping on the Y axis, and it will continue. The game will remember this top difference.
Finding The Direction of Collision
If Sonic is found to be touching the object, the game will then decide whether he is to be popped out the top or bottom, or the left or right of the object. The game will compare Sonic's position to the object's position to determine which side he is on.
To do this, the game will first determine which side Sonic is in comparison with the object's position.
If Sonic's X Position is greater than the object's X position, he's on the right, otherwise, he's on the left. If Sonic's Y Position is greater than the object's Y position, he's on the bottom, otherwise, he's on the top.
After the side is determined for each axis, the game will calculate a distance to the nearest edge.
Horizontal Edge Distance
If Sonic is on the left, the edge distance is simply equal to the left difference which is the distance to the left side and will be a positive number.
If Sonic is on the right, the distance will be flipped around.
x_distance = left_difference - object_x_diameter
This is effectively the distance to the object's right side and will be a negative number.
Whichever side it is, we will call this new distance the x distance.
Vertical Edge Distance
It is the same along the Y axis. If Sonic is on the top, the edge distance is simply equal to the top difference which is the distance to the left side and will be a positive number.
If Sonic is on the bottom, the distance will be flipped around (and that extra 4px from before will be subtracted).
top_difference -= 4 y_distance = top_difference - object_y_diameter
This is effectively the distance to the objects bottom side and will be a negative number.
Whichever side it is, we will call this the y distance.
Note: If Sonic is on the top, the extra 4px isnt subtracted yet. It will be subtracted upon landing.
Choosing The Direction
Finally, with all of this information, the game can decide which way Sonic should be popped out.
It does this by finding which side Sonic is nearer to, which makes sense.
if (absolute(x distance) > absolute(y distance))
{
collide vertically
}
else
{
collide horizontally
}
Here's a visual example of what axis Sonic would collide depending on his X Position and Y Position within the solid area of a block.
The horizontal axis is favoured just a little more than the vertical. Keep in mind this exact pattern is only valid for an object of this exact size and while Sonic is standing.
From there, the game can easily tell which way to pop out Sonic on either axis depending on the sign of the distance value. When colliding vertically, the game knows that Sonic is on top if the y distance is positive, and underneath if the y distance is negative. Same goes for left and right and the x distance.
Popping Sonic Out
Once a collision has occurred and the game had decided the direction Sonic then needs to be "popped out" of the object so that he is no longer in it, and his speeds need to be changed. But where does it put Sonic? Well, there's also an even greater use for the x distance or y distance. They are the exact distance Sonic needs to move to exit the object, but reversed. So when he is popped out, they will simply be subtracted from his position.
Popped Left and Right
Popping Sonic out left or right will simply reset his speeds and position, and set him to pushing if he is grounded.
There are a couple of conditions. The game will only bother popping Sonic out if absolute y distance is greater than 4. The game will also only bother touching Sonic's speeds if x distance is not 0.
If the game does decide to affect Sonic's speeds, this also depends on a few factors. If Sonic is on the left and the game has decided he needs to be popped out to the object's left side, it will only stop Sonic's speeds if Sonic is moving right (X Speed > 0), towards the object. The same is true for colliding with the right, but if Sonic is moving to the left (X Speed < 0). Basically, he must be moving towards the object. When his speeds are stopped, X Speed and Ground Speed are set to 0.
Regardless, x distance will be subtracted from Sonic's position, popping Sonic out of the object.
A few other things happen behind the scenes, such as the object is told it is being pushed, and Sonic is told he is pushing.
Popped Downwards
If Sonic bumps the bottom of an object, the game will check if Sonic is moving vertically (Y Speed is not 0). If not, the game then checks if Sonic is standing on the ground, and if he is, kills him from crushing, then exits.
Otherwise, the game checks if 'Y Speed' is less than 0. If not, it will exit as Sonic is moving down and away from the object.
Finally, if the y distance is smaller than 0, the game will subtract y distance from his Y Position and set his Y Speed to 0.
Popped Upwards
If the game decides Sonic is to be popped out upwards, Sonic will land on the object.
Before it does this, it checks if y distance is less than 16. If it is, the game will exit the landing code.
Then the game subtracts the 4px it added earlier from y distance.
Next, it will scrap the combined X radius we were using before, and find a new X radius, this being the actual X radius of the object, not combined with anything at all. So 16 in the case of a push block for example. It will then compare Sonic's position using this radius.
action_radius = 16 //an example
action_diameter = action_radius*2
x_comparison = action_radius plus object's X position
x_comparison -= sonic's X Position
//if sonic is too far to the right
if (x_comparison is less than 0)
{
exit;
}
//if sonic is too far to the left
if (x_comparison is greater than or equal to action_diameter)
{
exit;
}
This means Sonic will exit the landing and will just slip off the side keep falling if his "X Position" position isn't directly above the object, which is actually quite strange as it's as if Sonic is only 1 pixel thick.
The last check is if Sonic's Y Speed is negative, he wont land and it will exit.
Finally, if it reaches this far, he will land. From this point, it's rather simple.
The game subtracts y distance from Sonic's Y Position. It also subtracts an extra 1px afterwards to align him correctly.
Then it resets Sonic to be grounded, similarly to normal Reacquisition Of The Ground but simply sets Sonic's Y Speed to 0, and his ang to 0. Also, the game will set a flag telling the game Sonic is on the object.
Finally, Sonic's Ground Speed is set to equal his X Speed.
Specifics
As mentioned in Basics, Sonic's collisions with tiles and objects only concern themselves with Sonic's floored position (his pixel position), and the same applies to the object itself. So, upon the point of contact, Sonic's floored X Position finds himself overlapping the object. He is then pushed out by this difference. Since this difference only accounts for the distance between floored values, it's a whole number. Meaning if Sonic was 1px inside the object's right side while he has an X Position of 1.75, after being pushed out he'd have an X Position of 2.75, as a rough example.
So after being popped out, if Sonic keeps trying to walk towards it, he has to cover the rest of the distance of the pixel he's currently in before his pixel position overlaps the object again. This amounts to contact being made every 4 frames or so.
Standing On Solid Objects
Unlike tiles, which are an organised simple grid of data that can be easily checked each frame, objects are more expensive to check for.
So when standing on top of an object, rather than check beneath Sonic each frame to ensure he's still touching it and to move him with it, the game sets a standing-on-object flag which will effectively glue Sonic to an object when he lands on it.
The flag's job is making him stick to the object's surface and stay grounded, even though he's not touching any Solid Tiles (as far as his tile sensors are concerned, Sonic is in the air while standing on an object). This flag will only be unset when walking off the edge of an object or jumping/getting hurt.
Walking Off The Edges
If Sonic is standing on an object, the game will only check if Sonic has walked off of it.
First, it calculates a distance to the object's left side.
x_left_distance = sonic's X Position - the object's X //get the position difference x_left_distance += combined X radius //add the combined X radius
Sonic will have walked off the edge if this distance is less than 0 or is greater than or equal to (combined X radius * 2). When this happens, the standing-on-object flag is unset and Sonic is no longer grounded.
Moving On Platforms
After all checks are complete and if Sonic is still on it, the game handles moving Sonic with the object and keeping him stuck to it.
Bugs Using This Method
Overall, this method for collision with objects is pretty well made. However, there are a few obvious problems that become apparent when you mess with objects enough.
Slipping
As mentioned, since landing on the top of objects doesn't measure using the same radius as the rest of object collision, bizarrely this means if you jump down towards the corner of an object, you'll slip right off the sides because it exits the landing code if Sonic's position isn't right above the object. This appears to be deliberate as the smaller radius is very explicitly used, but doesn't add any benefit as far as I can tell.
The way the object collision code is executed, being from inside each object in order, there's effectively a priority system in place. If two objects want to push Sonic two conflicting ways, the one who executes their solid object code last will win out. Sonic cannot be pushed by two or more objects at the same time in 2 different ways. The result of this, and partly thanks to the edge slipping mentioned above, Sonic can very easily slip between two objects which haven't been placed perfectly touching next to each other.
Sonic will collide on top with both spikes, but his position isn't directly over either of them, so he will slip down the sides. Next, both spikes will try and push him with their sides, but only the last spike to do so will actually result in a net position change.
Bottom Overalap
When the vertical overlap is being checked, the game pretends Sonic is 4px lower than he actually is. This allows 4px of extra "grip" to the top of objects, however it also effectively removes 4px from underneath them. When jumping up into an object, Sonic will be able to enter it by around 4px before being popped out. Though, this is hard to notice during normal gameplay.
False Object Standing Flag
This final bug is less of a design flaw and more of a major bug.
If for some reason the object you are standing on is deleted or otherwise unloaded, and the game fails to reset the standing-on-object flag you can then start walking through the air. This is because the flag is telling the game that Sonic is still grounded even though there's no longer any object to be grounded to. Because Sonic's grounded, he won't fall. Additionally, he also won't be able to walk off the object's sides as the object isn't even there to check for it.
Object Specific Collision
While a general description of Solid Object collision may cover a pushable block or a solid rock, not all objects behave the same. Some objects have slopes, and some will change what kind of solidity they have to suit different situations.
Objects That Collide
Some objects like walking enemies, pushable blocks, and item monitors all have to land on and stick to solid ground. They typically do this by casting a single downward sensor, much like Sonic does, at their central bottom point. The same applies to wall collision.
Sloped Objects
You may have noticed some objects in the classic games are sloped, rather than box shaped. Like the Collapsing GHZ platform, the large platforms from marble, diagonal springs, or even the Spring Ramps in S2.
This is achieved by using the same code as normal, but injecting a different value to use as the surface y position of the object. To get this y position, the game checks against a sloped object's height array:
This height array is relative to the object's Y Position, and is centred on it's X Position. The game stores these height arrays compressed at half the size, as shown above. This is possible because the slopes never need to be steeper than a step of 2 pixels, so the game simply "stretches out" the array information when the array is read.
When a sloped object is acting solid to sonic, instead of using the y position of the top of the solid box, it instead reads the value from the array, and from there as far as the game is concerned, the object is as high as the array tells it. This continuously happens as Sonic passes over the object, resulting in smooth motion.
Differences To Tiles
There are no real angle values because the array is height information only, and no sensors are being used here. This means that Sonic will have an angle value of 0 as he walks on a sloped object, and won't jump off or be affected by slope physics at all. In addition, Sonic will be slightly "deeper" into the slopes than he would on solid tiles. This is because his centre point is always snapped to the slope, rather than one of his side floor sensors. It's most likely for these reasons that objects do not have angles steeper than what is shown above.
Jump Through Platforms
Jump through platforms are small objects which are only solid from the top. Since all Sonic can do with platforms is land on them, they use their own code to check for just that, and in a more scrutinised way.
First, it will check if Sonic's Y Speed is less than 0. If it is, it will exit the collision. This means it will only check for overlap with Sonic while he is moving down or staying still. This is why Sonic can jump right up through it.
Horizontal Overlap
Next, it will check for X overlap in the exact same way that it does when landing on a normal solid object, using the object's normal X radius. Complete with all it's issues. If there's an overlap, it will continue.
Vertical Overlap
Next, the Y overlap is where things get interesting.
The game calculates the platform's surface Y coordinate by subtracting the Y radius from the Y position.
Then Sonic's bottom Y is calculated by adding his Height Radius to his Y Position. It also adds 4 to this bottom Y for much the same reason as the normal solid object collision, it allows Sonic to collide even when he's 4 pixels above.
The first check is if the platform's surface Y is greater than Sonic's bottom Y. If it is, it will exit as the platform is too low.
Next, it will check a distance between Sonic's bottom and the platform's surface (platform's surface Y minus Sonic's bottom Y). If the distance is less than -16 or is greater than or equal to 0, it will exit as Sonic is too low.
If it reaches past all those checks, Sonic will land.
Popping Sonic Out
The distance from before is added to Sonic's Y position, plus an extra 3px. After this the normal landing-on-object things occur, such as setting his speeds and standing-on-object flag.
Walking Off Edges
Platforms also use a different walking off edges code to normal Solid Objects. And since it's up to objects what width radius they want to use, things can get a little inconsistent. It's mentioned above that objects add Sonic's radius to get a combined radius. This actually isn't always the case. Sometimes objects will just provide their unaltered width radius which is the case with platforms. This means not only will Sonic fall through the corners of platforms like any other object, but he will also walk off them just as easily, way sooner than he really should, unlike the normal object collision.
This was probably missed because Sonic doesn't need to push against these platforms, so it's much harder to notice if Sonic's Push Radius hasn't been applied.
After this of course, Sonic is still standing on it, so the game handles updating Sonic's position on the object and moving him if the object is moving.
Worthy of note, is that many objects share the platform's "walking off edges" code.
Sloped objects, like those that fall in Green Hill, and these platforms also provide the actual X radius rather than a combined one. There's also a likely reason for this too.
These have slope data, which is a height array, and the value returned from this is based on Sonic's X Position. So Sonic stands on them, and his current height on the platform is decided based on his X position relative to the object. If Sonic's Push Radius was added to the x radius used for Sonic to walk off the edges, and if Sonic could then hang off the edges slightly, the current height of the object's slope would be invalid causing odd results like Sonic being sent somewhere weird vertically due to an invalid height being read. This could be solved by just using the first or last height array value if Sonic's X Position is outside of the platform boundary.
Note: The code itself isn't the issue, the issue is moreso that the objects can far more easily pass in a radius that isn't combined when they use this because the general solid object code also uses the radius for pushing and for walking off, which requires it to be combined.
Pushable Blocks
Pushable blocks (specifically the type found in Marble Zone) are essentially normal solid objects, except for the fact when you are pushing them move. They move rather slowly, and you might assume that it sets the block and Sonic's speeds to some value like 0.3, but this is not the case.
The block actually moves 1 entire pixel whenever you touch it from the side. But that sounds much faster than they actually move right? Well, in practice the block will only move once around every 3 frames. And the reason for this is rather technical to say the least and requires that you properly emulate the way the original game's positions work.
Upon Contact
When Sonic has contacted the push block, Sonic has been popped out, and his speeds have been set to 0, the push block will then do some extra things. If Sonic pushed to the left, both Sonic and the block will move 1 pixel to the left, Sonic's X Speed is set to 0 and Ground Speed is set to -0.25. If he pushed to the right, both Sonic and the block will move 1 pixel to the right, Sonic's X Speed is set to 0 and Ground Speed is set to 0.25.
After being popped out Sonic is no longer touching the object. When this happens, Sonic's pixel position has been altered, but his subpixel position remains the same. So if Sonic was half a pixel into the object before, he's now half a pixel outside of it. Before he makes contact with the object again, he needs to cover this subpixel distance. This would normally take around 4 frames for a static wall, but here it instead takes 2-3 frames because he is given a headstart when his Ground Speed is set to .25.
Because the mechanics of movement within 256 subpixels are difficult to explain or visually demonstrate, here's what a few frames of pushing a pushable block to the right would look like:
Frame 0: -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.34375 -- added acc to Ground Speed X Speed: 0.34375 -- X Speed set to Ground Speed (on flat ground) X Position: 2669.97265625 -- added X Speed to X Position. Sonic's subpixel position (.972) is very close to entering the next pixel, which is where he will collide again. Frame 1: -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.390625 -- added acc to Ground Speed X Speed: 0.390625 -- X Speed set to Ground Speed (on flat ground) X Position: 2670.36328125 -- added X Speed to X Position. Sonic's X pixel has changed -- Sonic makes contact with push block and is popped out to the left. Ground Speed: 0 -- Ground Speed set to 0 X Speed: 0 -- X Speed set to Ground Speed (on flat ground) X Position: 2669.36328125 -- 1 subtracted from X Position -- The push block runs its own code and both are moved to the right by 1 pixel, and Sonic's Ground Speed is set. Ground Speed: 0.25 -- Ground Speed set to 0.25 X Speed: 0 -- X Speed set to 0 X Position: 2670.36328125 -- 1 added to X Position
At this point, Sonic has just pushed the block and has been moved out of it, then along with it. The fractional part of his position is currently .363 , just left of halfway through the pixel.
Frame 2 (1 frame since last push): -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.296875 -- added acc to Ground Speed X Speed: 0.296875 -- X Speed set to Ground Speed (on flat ground) X Position: 2670.66015625 -- added X Speed to X Position Frame 3 (2 frames since last push): -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.34375 -- added acc to Ground Speed X Speed: 0.34375 -- X Speed set to Ground Speed (on flat ground) X Position: 2671.00390625 -- added X Speed to X Position. Sonic's X pixel has changed -- Sonic makes contact with push block and is popped out to the left. Ground Speed: 0 -- Ground Speed set to 0 X Speed: 0 -- X Speed set to 0 X Position: 2670.00390625 -- 1 subtracted from X Position -- Sonic makes contact with push block and both are moved to the right by 1 pixel. -- This only took 2 frames, because Sonic's subpixel was positioned just right on the previous push, which is very rare. Ground Speed: 0.25 -- Ground Speed set to 0.25 X Speed: 0 -- X Speed set to 0 X Position: 2671.00390625 -- 1 added to X Position
Sonic has just pushed the block again, and has been moved out of it, then along with it. It took 2 frames. This time, the fractional part of his position is currently .003 , the very left of the pixel. This means he has farther to travel to reach the block again.
Frame 4 (1 frame since last push): -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.296875 -- added acc to Ground Speed X Speed: 0.296875 -- X Speed set to Ground Speed (on flat ground) X Position: 2671.30078125 -- added X Speed to X Position Frame 5 (2 frames since last push): -- Sonic gains speed along the floor naturally Ground Speed: 0.34375 -- added acc to Ground Speed X Speed: 0.34375 -- X Speed set to Ground Speed (on flat ground) X Position: 2671.64453125 -- added X Speed to X Position Frame 6 (3 frames since last push): -- Sonic gains speed along the floor naturally and moves his position Ground Speed: 0.390625 -- added acc to Ground Speed X Speed: 0.390625 -- X Speed set to Ground Speed (on flat ground) X Position: 2672.03515625 -- added X Speed to X Position. Sonic's X pixel has changed -- Sonic makes contact with push block and is popped out to the left. Ground Speed: 0 -- Ground Speed set to 0 X Speed: 0 -- X Speed set to 0 X Position: 2671.03515625 -- 1 subtracted from X Position
-- Sonic makes contact with push block and both are moved to the right by 1 pixel. -- This time, it took 3 frames, which is far more common. Ground Speed: 0.25 -- Ground Speed set to 0.25 X Speed: 0 -- X Speed set to 0 X Position: 2672.03515625 -- 1 added to X Position
Sonic has just pushed the block again, and has been moved out of it, then along with it. This time it took 3 frames thanks to his subpixel/fractional positions being allowed to wrap around and never reset. This 3 frame delay is the most common and is effectively the push speed.
The reverse would have the exact same timings. It seems they deliberately controlled this delay by adding .25 to his Ground Speed.
If you simply want to roughly copy it without the specifics or nuances of this system or you are using different object collision, just make a timer which triggers a movement every 3 frames while Sonic is pushing.
To see what happens to a push block once it is pushed off a ledge, see Game Objects.
Item Monitor
Item Monitors, as you may have noticed, are not always solid. While you can stand on them you can also go right through them while jumping or rolling. The game is actually checking what Sonic is doing and changing how the Item Monitor will react.
While not curled up in a ball, the Item Monitor acts as solid. The Item Monitor's hitbox isn't accessible at this time.
While curled, however, the item box will no longer have any solidity at all, and its hitbox is active and accessible. The hitbox collision is what destroys the Item Box and bounces Sonic off (Details in Monitors Rebound).
However, there is an exception. If Sonic is moving up (Y Speed < 0) while curled, the Item Box will in fact still act solid. Additionally, if Sonic's Y Position-16 is smaller than the item box's Y Position, the item box will bounce up with a Y Speed of -1.5 knocking the Item Box upwards, and Sonic's Y Speed will be reversed.