Actions

SPG:Solid Tiles

From Sonic Retro

Revision as of 12:08, 23 February 2022 by LapperDev (talk | contribs) (Grammar fixes)
Sonic Physics Guide
Collision
Physics
Gameplay
Presentation
Special

Notes:

  • The research applies to all four of the Sega Mega Drive games and Sonic CD.
  • The following only describes how the Player object collides and interacts with stage terrain. Solid objects, such as Monitors, Jump Through Platforms, and Pushable Blocks each have their own collision routines with the Player and don't necessarily behave exactly the same as the tiles do. For this, refer to Solid Objects.
  • This page describes what Solid Tiles and Sensors are and how they work. For their use in player collision and movement, see Slope Collision (part 1) and Slope Physics (part 2).

Introduction

What are solid tiles? While there are often solid objects in Sonic zones, the zone itself would require far too much object memory if the environment were constructed entirely of solid objects, each with their own 64 bytes of RAM. A clever short-cut is used - the zone is constructed out of tiles anyway, so all that needs be done is have each tile know whether or not it is solid.

You may know that zones are broken down into 128x128 pixel chunks (or 256x256 pixel chunks in Sonic 1 and Sonic CD), which are in turn broken into 16x16 pixel blocks, which are again in turn broken into even smaller 8x8 pixel tiles. All of the solidity magic happens with the 16x16 blocks, so those are the only ones we will be interested in throughout this guide.

The Player object's collisions and interactions with these solid tiles are what make up their basic engine. They dictate how the Player handles floors, walls, ceilings, slopes, and loops.

First we will look at how the environment is constructed from tiles, and then the Player's method for detecting their environment.

Solid Tiles

Solid tiles are what define the terrain solidity in a stage. The shape of slopes, and the angles of them.

Block Grid

For the purposes of this guide, the "solid tiles" are the actual solidity data used to define the ground shape. But the structure they belong to are "Blocks". Each Sonic stage essentially contains a grid of 16 by 16 px Blocks (grid cells) that fill a stage (or more specifically, fill each predefined terrain "Chunk"). Each of these Blocks references a solid tile (or empty solid tile) from a list of predefined solid tiles which contain height array data that contains the filled (solid) area/shape for that Block. Each Block can also define other properties for it's Solid Tile such as flipping or flagging.

Height Array

Now for the solid tiles themselves. How is a solid tile set up? How is the shape of the terrain formatted?

Each Solid Tile is simply an array of 16 height values that can range from 0px ($00) to 16px ($10) inclusive. Solid tiles also have a single angle value associated with then.

SPGHeightMask.PNG

This tile's height array has the values 0 0 1 2 2 3 4 5 5 6 6 7 8 9 9 9, and has the angle 33.75° ($E8).

Solid tiles also have another height array (or, well, a width array) for horizontal collisions. This other array represents the same data and creates the exact same shape within the tile.

Flagged Tiles

Nearly all tiles have a specific angle value which is used to allow the Player to rotate with sloped ground. However, some tiles angle is used as a flag. In the original games, if the angle of the tile is 255 ($FF), it is a flagged tile. How this angle is reacted to is determined by the object's code. In the case of the Player, they will not set their Ground Angle to the tile's angle as normal, but will instead find a new Ground Angle which is the Player's current Ground Angle snapped to the nearest 90° increment.

This flag applies to all full block solid tiles (filled squares), as it is a quick and easy way to allow the Player to walk on all sides of a full block without needing to flip it around or provide multiple angle values for each side. This is also used as a trick to effectively "flatten" the end of ramps. The ramps found in Emerald Hill Zone end with a diagonal slope - yet Spindashing up it sends you flying directly upwards into the air. How? The trick is that the last tile on that ramp has an angle of 255 ($FF), so is flagged despite not being a flat tile. This snaps the Player to 90° (aka, moving directly upwards) just as they leave the ramp.

Flipping Tiles

You may rightly wonder how sloped ceilings are possible if the height array starts at one end only. The answer to this is that Blocks can be flipped horizontally and/or vertically. The collision systems take this into account when reading the height data from that Block's tile. The angles of flipped tiles are also adjusted when being checked.

Tile Solidity

Not all tiles behave the same. Some tiles are only solid from the top, some only from the sides, and some of course are solid from all sides. This solidity aspect affects which directions of sensors can detect them. For example, a "top only" tile will be ignored by sideways and upwards facing sensors, but downward facing sensors will detect them.

What are sensors? Well, that's up next.

Sensors

"Sensors" are simply checks performed by objects which look for solid tiles around them.

An x/y position (anchor point) is checked, and if it finds a solid tile, they will gather information about the tile. Sensors can point down, right, up, and left, and all behave the same in their respective directions.

SPGSensorAnchors.png The white points represent the anchor positions of the Player's sensors.

In this example, the sensor to the Player's mid right points right, and those at the Player's feet point down. Their direction dictates in which direction they are looking for a surface. A sensor pointing right is looking for the leftmost edge of solid terrain nearby, a sensor pointing down is looking for the topmost edge of solid terrain nearby.

Which value of the height array is used? Subtract the tile's X position from the sensor's X position. The result is the index of the height array to use.

So, now we know Sensors are points which look for solid tiles they touch, and that they can check the height of tiles at specific positions to get the floor surface position.

However, this is not the whole picture. If a sensor finds an empty tile or the array value of the tile found by the sensor is 16 (a full block amount), then it's likely that the surface of the solid terrain is actually found within an adjacent tile instead.

Sensor Regression & Extension

So when a sensor check is performed at a sensor's anchor point it has either found a solid tile, or it hasn't. If it has, what if the height value found is 16 and isn't actually the surface of the terrain? Or if it hasn't, what if there's a solid tile nearby?

Well, this is easily solved by checking neighbouring tiles if certain conditions are met.

Note:

  • The following is an example in the case of a sensor which is pointing down looking for solids below (like a floor sensor while standing upright).
  • The current height array value of a tile at the sensor's X position will be referred to as the tile height.
Normal

When the anchor point finds a Solid Tile and the tile height of the first tile is between 1 and 15 (inclusive), the game can be sure the surface of the terrain has been found without needing to check extra tiles at all.

Otherwise, one of the following 2 things will happen.

Regression

When the anchor point finds a Solid Tile and the tile height of the first tile is 16 (meaning the tile is completely filled in that position), it will check up by 1 extra Solid Tile. We'll call this the "regression" since it goes back against the sensor direction.

If a regression occurs and tile height of the second tile is 0 (or the tile is empty), it will just default to processing the first tile, as the first tile must be the terrain surface.

Extension

When the anchor point just finds an empty tile (or the tile height of the first tile is 0), it will check down by 1 extra Solid Tile. We'll call this the "extension" because it goes outwards, in the direction of the sensor.

If an extension occurs and just finds an empty second tile (or the tile height of the second tile is 0), the game knows that no terrain or terrain surface has been found, and will return the distance to the end of the second tile checked.


If a solid tile was found to be processed, it will calculate the distance between that tile height and the sensor.

SPGSensorDistance.gif

In the above example, a downward facing sensor moves down through 3 Solid Tiles. We can see the tiles it checks, and the distance it returns at each position. We can also see if it is performing extension or regression. You can see this means the sensor can effectively act as a line, it can regress or extend up to 32 pixels to find the nearest surface.

The regression & extension will occur in the direction of the sensor, be it horizontal or vertical. If the sensor is horizontal, it reads the other height array belonging to the tile, using the sensor's y position. Essentially rotating the entire setup. So a right facing sensor's regression would check an extra tile to the left, and extension would check an extra tile to the right. While an upward facing sensor's regression would check an extra tile below, and extension would check an extra tile above.

With all this, a sensor can always locate the nearest open surface (and the tile containing that surface) of the terrain within a range of 2 tiles (the tile the sensor anchor point is touching plus another).

Reaction

Once a final suitable tile has been found, information about the tile is returned.

The information a sensor finds is as follows:

  • The distance from the sensor pixel to the surface of the solid tile found (in the sensor's direction)
  • The angle of the tile found
  • The tile ID
Distance

The distance to the solid tile surface (found by the sensor) is the most important piece of information dictating how an object will react to solid tiles. It's not the distance to the tile, it's the distance to the edge of the solid area within the tile, precisely.

The distance can either be 0, negative, or positive.

When no Solid Tile is found by a sensor, the sensor will return a distance between 16 and 32 (inclusive), which is the distance to the end of the second tile checked. When casting sensors, objects check the returned distances it accepts for collision. For example, checking if a distance is > 14 and if it is, not colliding. This will effectively filter out these potentially no-tile-found distances. This avoids a need for the game to remember after the sensor was cast if a tile was found. In future, if the guide references a tile not being found, this means either the distance is out of the range the object wants, or the distance is between 16 and 31. Of course, most of the time an object will only react to negative distances which automatically rules these out anyway.

  • A distance of 0 means the sensor is just touching the solid tile surface and the object will not need to move (but may still choose to collide).
  • A negative distance means the surface found is closer to the object than the sensor position. Negative distances are almost always reacted to when colliding, because it indicates that the object is inside the solid and can be pushed out.
  • Positive distances mean the surface found is further away from the object than the sensor position. Since this means the object isn't actually touching the tile, it's rarely used - but not never. A notable example of it's use is by floor sensors of various objects, including the Player, to keep them attached to the ground even if the ground has sloped away from them a bit as they move. Objects usually employ a limit to how far an object can be "pulled" down to a solid they aren't actually touching. This will be detailed further down for the Player.

If the object decides to snap itself to the terrain, it simply has to add the distance value to it's position. Or subtract, depending on the sensor's direction. A sensor pointing left may return a negative distance if it is inside a solid, but the object would have to subtract the distance in order to move to the right, out of it.

Of course, as stated, this distance can be representative of any 4 directions, depending on the sensor's own angle.

Summary

Here's a demonstrative animation showing a very simplified process of how the floor sensors detect a tile and be moved upwards. In this case, the Player will have a Ground Speed of 6.

SPGSensorProcess.gif

Visual Depiction

Throughout this guide these sensors will be drawn as lines. But, they are not. Or well, they are, but not quite as shown.

Sensors will be drawn from the sensor anchor, extending towards the centre of the object. You can imagine it like so - if the exact surface pixels of the ground is within these lines, the Player will be pushed out. It is of course not quite this simple in reality. As shown in the previous visualisation of a sensor, the "line" portion can extend up to 32 pixels in either direction, all depending on where the sensor anchor currently sits within it's tile... This would be impossible to accurately draw over the Player while keeping things understandable and clear. This visualisation is the most easy to visualise way to think about the solidity on a surface level.

Just be aware that the line based depictions are for simple illustration purposes only and the endpoints of the lines are the active sensor anchors (which always behave as described).