An overview of physics in Sonic games. Part 1: solid tiles

From the translator : this post is a translation of one of the parts of the Sonic Physics Guide in the games of the Sonic the Hedgehog series for Sega Genesis / Mega Drive and Sonic CD . The following sections cover topics such as running, jumping, spinning, losing rings, underwater behavior, super speed, accessibility, camera, animations, and some others. Since there are a lot of parts ( 14 pieces ), at the end of the post I added a survey. Should you continue - you decide.

Links to other parts of the series:
Part 2: running
Parts 3 and 4: jumping and spinning
Parts 5 and 6: losing rings and being under water
Parts 7 and 8: springs and gizmos, super speeds

• 1. Introduction
• 2 Standing
• 3 push
• 4 fall
• 5 Balancing on the edge
• 6 Slopes and curves
  
  • 6.1 Masks of heights
    
    • 6.1.1 Errors Using This Method
  • 6.2 Angular movement
    • 6.2.1 Three speed variables
    • 6.2.2 Slope coefficient
  • 6.3 Jumping at angles
• 7 Switching modes
  
  • 7.1 Four modes
  • 7.2 Falling from walls and ceilings
    
    • 7.2.1 Sliding back
• 8 Airborne status
  
  • 8.1 Airborne Colliders
    
    • 8.1.1 Horizontal Collider
    • 8.1.2 Vertical Colliders
  • 8.2 Jumping “across” the floor
  • 8.3 Earth re-detection
    
    • 8.3.1 When moving down
    • 8.3.2 When moving up
• 9 Help: Converting Angles
• 10 notes

Note

This article describes Sonic's collisions and interactions with solid tiles. Solid objects, such as monitors, moving platforms and blocks, have their own collision handling procedures with Sonic, which do not necessarily coincide with the behavior of solid tiles.

Introduction

What are solid tiles? There are a lot of solid objects in the zones (levels) that make up Sonic games, so a zone would require too much memory if the environment were entirely composed of solid objects, each of which occupies 64 bytes of RAM. A smart move was made - the zone is created from tiles, so all that is required is to know whether the tile is solid (impermeable) or not.

You may know that the zones are divided into blocks of 128x128 pixels (or 256x256 pixels in Sonic 1 and Sonic CD), which, in turn, are divided into tiles of 16x16 pixels; they are also broken down into smaller tiles of size 8x8 pixels. All the magic of processing solid elements occurs at the level of 16x16 tiles, so in this review we will be interested only in them.

Sonic’s interaction and collisions with these solid tiles form the core game engine. They determine how to work with floors, walls, ceilings, ramps and hinges. Since this is a voluminous and complex topic, my review will be different from other Sonic game physics guides, but I will try to limit my reasoning to a minimum.

Standing



If we take the position of the earth along the Y axis equal to 736 ($ 02E0), then Sonic stands above it at coordinate 716 ($ 02CC). It is 20 pixels above ground level.



Sonic's push must stop when hitting a wall. This can be achieved by checking the collision with the line. The collider line ( from the translator: here and hereinafter, the term sensor is used, I have chosen, it seems to me, an adequate analogue ) should not be in its position on the Y axis, but a little lower, otherwise it will “not notice” short steps. She also cannot be too low, otherwise she will “notice” the slopes and curves, from which Sonic should not push off. Its location in Y + 4 coordinate from Sonic's location will be sufficient, because usually there are no stairs below 16 pixels in height (when such stairs exist, they consist of solid objects, not tiles).

How wide should the collider line be?



If we take the X coordinate of the left side of the wall equal to 704 ($ 02C0), then Sonic should not be closer than 693 ($ 02B5). If we take the X coordinate of the right side of the wall equal to 831 ($ 033F), then Sonic should not be closer than 842 ($ 034A). This amounts to a difference of 11 pixels in both directions.

Therefore, the collider line should have a width of 20 pixels, and be stretched from X-10 to X + 10 Sonic. Each time a solid tile is detected, Sonic should be “pushed out” by setting the tile coordinate minus (or plus) 11, while the speed of movement on the ground should be zeroed. (It cannot be pushed out only 10 pixels, otherwise the point with the coordinates X + 10 will still be inside the boundary pixel of the tile. In this case, a constant collision will be registered and it will stick to the wall.)

Since the border of the tile minus the position of Sonic should be 11, there are only 10 free pixels between the center of Sonic and the border of the tile. The eleventh pixel from Sonic will be the very edge of the tile. Therefore, Sonic actually has a width of 20 pixels.

Fall

Sonic should be able to escape from the sites. He cannot behave like the cartoon Wile E. Coyote coyote, not noticing that there is nothing beneath him.



This means that Sonic should also check for solid tiles underneath. This can be achieved by adding two more lines of colliders pointing down. One (A) should be on the left side of Sonic, at X-9 coordinate. The other (B) is on the right side, at X + 9. They should start from its position along the Y axis and fall no less than 16 pixels below his feet at ground level, which is located at Y + 20 (but not too low, or he will fall down when descending from low steps or stairs, which we would not want to).

If colliders A and B do not detect solid tiles, Sonic “falls” - a flag is set that informs the engine that it is in the air.

We remember that in a collision with the walls, Sonic has a width of 20 pixels. However, ground detection colliders are only 18 pixels from the center. It turns out that Sonic is “2 pixels thinner” when escaping from the sites than when hitting the walls.

Balancing at the edge

A good detail - Sonic goes into the balancing animation, being close to the edge of the site. This happens only when he stops (his speed on the ground is 0).

How does the engine know about this? Everything is simple - at the moment when only one of the colliders is active, Sonic is on the edge. If A is active, but B is not, then the site is to the right of it. Otherwise, the site is on the left.

However, if Sonic starts to balance, immediately, as soon as one of the colliders does not find anything, he will begin to balance “early”, and it will look silly. Therefore, this happens when only one collider is active, and its position on the X axis is greater than the boundary of the solid tile detected by the active collider.



If we take the coordinate of the right edge of the site equal to 2655 ($ 0A5F), Sonic will begin to balance only at 2656 ($ 0A60). It will fall at 2665 ($ 0A69) when both colliders find nothing.

In Sonic 2 and Sonic CD, if the site is in the opposite direction from Sonic's view, then the second balancing animation is turned on.

In Sonic 2 , Sonic 3, and Sonic & Knuckles, Sonic has a third balancing animation when it is even closer to the edge of the pad. Given the above values, it turns on when it is at coordinate 2662 ($ 0A66).

Note: when balancing, some features are not available (pressing to the ground, looking up, rotation, etc.). INA Sonic 3 & Knuckles player can snuggle to the ground and spin (but not look up) while balancing on the ground, but not when balancing on the subject.

Slopes and Curves

Sonic the Hedgehog was one of the first games to use curved surfaces and loops with a 360-degree rotation. In most games of that era, the environment was completely created from blocks (and sometimes from slopes).

The ability to work with objects that smoothly change shape is one of the fundamental aspects of the novelty and attractiveness of Sonic games. Unfortunately, this is probably the most difficult aspect to recreate in fan games.

How does he work?

Height Masks

Each time colliders A or B detect a solid tile, they return the height of that tile.

How is the tile height?

Each tile has a value associated with it, tied to a mask stored in memory. A mask is a simple array of 16 height values ​​ranging from 0 ($ 00) to 16 ($ 10) and angle values.



For example, this height mask has an array of heights 0 0 1 2 2 3 4 5 5 6 6 7 8 9 9 9 and an angle of 232 ($ 00 00 01 02 02 03 04 05 05 06 06 07 08 09 09 09 and an angle of $ E8).

What is the height array value used? Subtract the X position of the tile from the X position of the collider. The result will be the used height array index.

If the found height value is 16 ($ 10), then the collider should check another tile above the first found one and determine its height value.

Whatever collider detects the highest height, Sonic's Y coordinate is set equal to that height minus 20 pixels. Its angle is also set equal to the angle of the solid tile, which returned the highest height.

If the collider does not detect a solid tile, the default is to return the foot level (Y + 20).

Errors when using this method

Unfortunately, due to the use of this method in the original engine, there are a couple of annoying bugs.

If Sonic is standing on an inclined platform, one of the colliders will not detect the tile, and will return the height of the level of the legs. This leads to the fact that Sonic is in the wrong position.



Sonic rises with Collider B when moving to the right. When B "falls" from the site, Sonic by default moves to the level of collider A. Then he rises with collider A with a further move to the right. Therefore, he will first rise, fall and rise again when he escapes from the site.

There are only a few areas in which this is noticeable, but such a bug is present in all parts of the game for Genesis / Mega Drive, and it looks rather messy.

The second bug occurs if there are two tiles of opposite slopes one above the other, such as low hills at the Green Hill Zone and Marble Zone levels .



Collider B starts to descend from the slope to the right, but Sonic still defaults to the level of the previous slope detected by Collider A. Since these slopes are quite low, this lowers Sonic in the middle by about 1 pixel.

But that is not all. Sonic receives angle data from the highest collider, so even if it looks like it should be at the slope angle to the right (because it is closer to it), it will still have a slope angle to the left. When jumping, he will jump at this angle, moving backward, and not forward, as expected.

Moving at angles

All this is very good and wonderful - Sonic moves smoothly on the surface with various heights. However, the engine needs to do something else. For realism, the speed of Sonic should be reduced on surfaces at an angle.

There are two ways angles can affect Sonic's speed. The first ensures that it does not run over the hill at the same time as on flat ground of the same width. The second slows it when moving up the hill and speeds it up when moving down. Let's look at each of them in turn.

Three speed variables

If Sonic was an ordinary platformer using only blocks, he would need only two speed variables: movement along the X axis ( Xsp ) and along the Y axis ( Ysp ), horizontal and vertical components of Sonic's speed. Acceleration ( acc ), deceleration ( dec ), and friction ( frc ) are added to Xsp ; jump speed ( jmp ) and gravity ( grv ) are added to Ysp (when Sonic is in the air).

However, when using ramps, when Sonic moves along the ramp, he simultaneously moves horizontally and vertically. This means that both Xsp andYsp have nonzero values. Just adding acc , dec or frc to Xsp no longer works; Imagine that Sonic is trying to run up the wall - adding to the horizontal speed will be useless, because he is trying to move up.

The trick is to use the third variable speed (which is what the original engine does), let's call it ground speed ( Gsp ). This is Sonic's speed along the earth, regardless of the angle. The values acc , dec, and frc are added to Gsp , not to Xsp or Ysp .

When on the ground, Xsp and Ysp are retrieved from Gsp at each step before moving Sonic. I think the pseudo-code example would be appropriate here:

Xsp = Gsp*cos(angle);
Ysp = Gsp*-sin(angle);
X += Xsp;
Y += Ysp;

Regardless of the angle change, the speed Gsp is maintained, so the engine always knows at what speed Sonic is “truly” moving.

Slope Ratio

Sonic can now handle interactions with any hills while maintaining accurate speed. However, he still needs to slow down during the ascent and accelerate during the descent.

Fortunately, this is easily achieved using the notion of slope coefficient ( slp ). We will just add slp * sin ( angle ) to Gsp at the beginning of each step. The running slp value is always 0.125 ($ 0020), but different when spinning. When Sonic spins up a hill ( Gsp is not equal to sin ( angle )), slp is 0.078125 ($ 001E). When rotating down a hill (sign Gspequal to the sign of sin ( angle )) slp is 0.3125 ($ 0050).

Note: it seems that in Sonic 1, the slp value is not added if Sonic stops and is in a standing / waiting cycle. However, in Sonic 3 & Knuckles, the slp value is added even in this case, so Sonic cannot stand on steep slopes - he has to go down them back.

Jumping at angles

The angle at which Sonic stands at the time of the jump also affects the jump. He can't just set Ysp to jmp , he needs to jump away from the angle at which he stands. Therefore, the jmp value must be assigned to both Xsp and Ysp , using cos () and sin () to get the correct values.

Some more pseudo-code:

Xsp -= jmp*sin(angle);
Ysp -= jmp*cos(angle);

Switching modes

So, Sonic can run on hills, slopes and platforms, and this is already not bad. But this is not enough. He cannot make his way from the earth to the walls and ceiling without an additional code.

Why? Land colliders A and B check obstacles directly below them, finding the height of the earth. They cannot handle the transition to the walls in any way, because the whole scheme is designed to move exactly up and down along the Y axis.

How to solve this problem? Using four different driving modes. This requires a little explanation.

Four modes

It is quite logical to assume that if Sonic can move 360 ​​degrees, the engine handles all 360 degrees in approximately the same way. In fact, the engine divides the angles into four quadrants, which greatly simplifies the work.

For a better understanding of what I'm talking about, imagine a simple platformer without full loops, only with low hills and slopes. All the character needs to do after moving horizontally is to move up or down until he reaches the floor level. Then you need to measure the angle of the floor. Angle is used to reduce Gsp , and for nothing more. The character will still always move horizontally and move strictly up and down to reach the floor level.

Mostly the same thing happens in games about Sonic. Only if the angle becomes too steep does Sonic change the “quadrant”, switching from floor mode to right wall mode (then to ceiling mode, left wall, and back to floor mode, and so on). At any moment in time and in any individual mode, Sonic behaves as in a regular platformer. Magic comes from combining these four modes with smartly made smooth switching between them.

But how and when does Sonic switch between modes?

If an angle greater than 224 ($ E0) is detected while in floor mode, the engine switches to the right wall mode. Basically, everything remains the same, only colliders check the right side instead of the bottom, and Sonic moves to the “floor” level horizontally rather than vertically.

If an angle less than 224 ($ E0) is detected while in the right wall mode, the engine switches back to floor mode.

Other transitions work in a similar way.

A fair question may arise - where are the earth colliders when we are in the right wall mode? They are located there, but rotated 90 degrees. Collider A is located relative to the center of Sonic at Y + 9 instead of X-9. Collider B is in Y-9 instead of X + 9. The collider lines do not become vertical, but horizontal, stretching 16 pixels beyond the level of his legs (which is now 20 pixels “lower” Sonic, at the coordinate X + 20).

Yes, since the colliders move, Sonic can be “pushed” to a new position in the step at which the mode switches. However, the movement is only a few pixels, and in an ordinary game it is completely imperceptible.

Another aspect: as I said, solid tiles consist of arrays of heights. The key word here is "height". How do they behave in the right wall mode? In a rather surprising way - it turns out that in the original engine each solid tile has two complementary heights; one is used for horizontal and the other for vertical movement.

What about the left wall and ceiling modes? Don't you need four arrays of heights? No, because tiles of this form use ordinary heights arrays, only inverted. In ceiling mode, Sonic knows that the found height value should be used to move it down, not up.

Thanks to these four modes, Sonic can move around all kinds of contours, internal and external curves, and so on. Here are a couple of examples of images with angle values ​​that will explain to you what we are talking about:





Falling from walls and ceilings

While in the right-wall, left-wall or ceiling mode, Sonic falls when the absolute Gsp value falls below 2.5 ($ 0280) ( Gsp at this moment is set to 0, however Xsp and Ysp do not change, so Sonic can continue to move along its trajectory in the air). This happens even when there is land beneath it.

Sliding backward

When Sonic falls in the manner described above, the horizontal control lock timer is set to 31 ($ 1E) (the timer does not start the countdown until Sonic touches the ground). While the timer value is not equal to zero, and Sonic is on the ground, he does not allow the player to change the speed of Sonic with the buttons "right" and "left". The timer value decreases by 1 with each step, so the lock lasts about half a second. During this time, only slp and the speed at which Sonic fell to the ground affect the movement , so Sonic will slide down the ramp.

The state of being in the air

When Sonic is in the air, you do not need to worry about angles, Gsp , slp and so on. All that is needed is to move using Xsp and Ysp until contact with the ground is detected, and then switch to ground mode.

However, Sonic has an unusual set of colliders for moving in the air, which is worth considering in detail.

Airborne Colliders

The horizontal collider

Sonic must hit the walls the same way he does it while on the ground. Therefore, there is a line of the horizontal collider starting from its position Y and stretching from X-10 to X + 10. In a collision with a solid tile, Sonic “pushes” to the border of the tile plus / minus 11, as well as being on the ground.

The difference is that this collider line is wider than the vertical colliders A and B, detecting the presence of land (we will return to them a little lower). This means that the horizontal collider line can detect the block that Sonic flies past, even if it does not have Xsp at all . Therefore, it slides off solid objects when it hits its extreme edges.

When Sonic detects a collision with this horizontal collider line, hisXsp is only reset if it moves toward the wall, not from it. Otherwise, he would stick to the walls, flying past them.

Vertical Colliders

Sonic Colliders A and B act in the air in much the same way as on the ground. The difference is that when a solid tile is detected, Sonic’s height is not immediately set equal to the height found for the tile, minus 20 pixels. Instead, this height is set only when it is already below that height. Otherwise, he would have stuck to the floor as he approached him.

If the colliders are stretched so far below his legs, why can't they detect the ground again in the step in which he jumps and never let him ever come off the floor? It's simple: he ignores them, except for those moments when Ysp is equal to or greater than zero, so he only detects the earth when moving down.

Since Sonic in the air can move both up and down, there must be two more colliders checking from above (C and D) so that he can hit the ceiling and the curves located above it. (C and D are exact specular reflections of A and B - they have the same X position and length, only directed not down, but up.) Sonic detects ceilings and pushes away from them, moving both up and down, unlike floors that are detected only when moving down. You can hit the “ceiling” (which is actually the bottom of the block) when moving down, clinging to a wall in which there is a gap, or jumping to the side of the upper curve.

Jumping “across” the floor

There are sites that Sonic can fly through and through when jumping up. They are often found in hilly green areas such as the Green Hill Zone , Emerald Hill Zone , Palmtree Panic Zone and so on. The solid tiles that make up such pads are marked by the engine as having a special type that can only be detected by the A and B colliders. They are ignored by the C and D colliders, as well as the horizontal collider line.

Re-discovery of the Earth

When Sonic is on the ground, Xsp and Ysp are obtained from Gsp . When it falls or otherwise breaks off the ground, Xsp and Ysp already contain the necessary values ​​to continue the trajectory in the air. But when Sonic lands, the Gsp must be calculated from the Xsp and Ysp available at the time of landing. You might think that cos () and sin () are used to get the exact value, but that is not the case. In reality, something much simpler happens, and the algorithms differ when they hit the curved ceiling and when they land on the curved ground, so I will consider them separately.

When moving down

If the angle of the detected earth is in the range of 240-255 ($ F0 ~ $ FF) (and their specular reflections are 0-15 ($ 00 ~ $ 0F)), Gsp is assigned the value Xsp . If the angle is in the range 224-239 ($ E0 ~ $ EF) (16-31 ($ 10 ~ $ 1F)), Gsp is assigned the value of Xsp , but only if the absolute value of Xsp is greater than Ysp . Otherwise, Gsp is equal to Ysp * 0.5 * -sign (cos ( angle )). If the angle is in the range 192-223 ($ C0 ~ $ DF) (32-63 ($ 20 ~ $ 3F)), Gsp is equal to Xsp if the absolute value of Xsp is greater than Ysp. Otherwise, Gsp is assigned the value Ysp * -sign (cos ( angle )).

When moving up

If the angle of the detected ceiling is in the range 160-191 ($ A0 ~ BF) (64-95 ($ 40 ~ $ 5F)), Sonic attaches to the ceiling, and Gsp takes the value Ysp * -sign (cos ( angle )) . If the angle is in the range of 96-159 ($ 60 ~ 9F), Sonic hits his head like a normal ceiling and does not attach to it. Ysp is reset, and Xsp is not changed.

Help: converting angles

Genesis / Mega Drive games use angle values ​​in hexadecimal, from 0 ($ 00) to 255 ($ FF), so the circle is not divided into 360 parts, as we used to, but to 256. What's worse, unlike corners in other languages, such as GML, they are counted counterclockwise, so 32 ($ 20) is not 45 °, as it should, but 315 °.

To convert the original hexadecimal angles to angles that can be used in GML, use this formula (written in pseudo-code):

return (256-hex_angle)*1.40625;

Notes

• Sonic can slow down ("creaking" with his legs) only in the floor mode.
• Sonic cannot jump if there is a low ceiling above him. If a collision is detected in Y-25 with a collider line located from X-9 to X + 9, then Sonic will not start jumping.
• At different times, Sonic has different heights. When it stands, runs, falls or takes off on a spring platform, it has a height of 40 pixels. Its position along the Y axis is always its center, so it always stands 20 pixels above the ground (and 20 pixels under the ceilings when it hits them). However, when jumping and rotating it has a height of only 30 pixels, and is raised 15 pixels above the ground (and also lowered 15 pixels below the ceiling, etc.). In the step in which Sonic spins or jumps, the slider adds 5 to its Y position, so even though it becomes shorter and its center changes position, the position of the bottom point does not change. When rotation is completed or landing after a jump, 5 pixels are subtracted from Y. The camera system must also take this offset into account, otherwise the view will also change when Sonic’s height changes.
• Colliders A, B, C and D described in this review are located at coordinates X-9 and X + 9. This is true only when walking, falling, pushing away from the spring platform and so on - always when it is not folded into a ball. If Sonic spins or jumps, they are at coordinates X-7 and X + 7. However, its horizontal collider line always remains the same.

Update: added decimal values.