|
|
| (89 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| | + | {{SPGPages}} |
| | '''Notes:''' | | '''Notes:''' |
| − | The research applies to all four of the [[Sega Mega Drive]] games and ''[[Sonic CD]]''. | + | *''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 [[Monitor|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 [[SPG:Solid_Objects|Solid Objects]]''. |
| − | Following only describes how [[Sonic the Hedgehog|Sonic]] collides and interacts with solid tiles. Solid objects, such as [[Monitor|Monitors]], Moving Platforms, and Blocks each have their own collision routines with Sonic and don't necessarily behave exactly the same as the tiles do.
| + | *''This page describes what Solid Tiles and Sensors are and how they work. For their use in player collision and movement, see [[SPG:Slope Collision|Slope Collision]] (part 1) and [[SPG:Slope Physics|Slope Physics]] (part 2)''. |
| − | | + | *''This page is essentially part 1 of 2. This details what Solid Tiles are and how they are used directly. For part 2, detailing how Solid Tiles and collision layers are used to create anything from simple slopes all the way to bigger Sonic set-pieces like loops, go to [[SPG:Solid Terrain|Solid Terrain]].'' |
| − | Degree angles are counterclockwise with 0 facing right (flat floor).
| |
| − | | |
| − | [[Image:SPGAngles2.png|link=Special:FilePath/SPGAngles2.png]] | |
| − | Dark blue represents ground, light blue represents air.
| |
| − | | |
| − | Different calculations may be needed if using the hex angle values.
| |
| − | | |
| − | ==Variables==
| |
| − | | |
| − | The following variables/constants will be referenced frequently in this section.
| |
| − | | |
| − | <nowiki>//Variables
| |
| − | xpos: The X-coordinate of Sonic's center.
| |
| − | ypos: The Y-coordinate of Sonic's center.
| |
| − | xsp: The speed at which Sonic is moving horizontally.
| |
| − | ysp: The speed at which Sonic is moving vertically.
| |
| − | gsp: The speed at which Sonic is moving on the ground.
| |
| − | slope: The current slope factor (slp) value being used.
| |
| − | ang: Sonic's angle on the ground.
| |
| − |
| |
| − | //Constants
| |
| − | acc: 0.046875
| |
| − | dec: 0.5
| |
| − | frc: 0.046875 (same as acc)
| |
| − | top: 6
| |
| − | jmp: 6.5 (6 for Knuckles)
| |
| − | slp: 0.125
| |
| − | slprollup: 0.078125
| |
| − | slprolldown: 0.3125
| |
| − | fall: 2.5
| |
| − | </nowiki>
| |
| | | | |
| | ==Introduction== | | ==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. |
| | | | |
| − | 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 ''128''x''128'' pixel chunks (or ''256''x''256'' pixel chunks in ''[[Sonic 1]]'' and ''[[Sonic CD]]''), which are in turn broken into ''16''x''16'' pixel Blocks, which are again in turn broken into even smaller 8x8 pixel tiles. All of the solidity magic happens with the ''16''x''16'' Blocks, so those are the only ones we will be interested in throughout this guide. |
| − | | |
| − | 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 pixels tiles, which are again in turn broken into even smaller 8x8 pixel tiles. All of the solidity magic happens with the 16x16 tiles, so those are the only ones we will be interested in throughout this guide. | |
| − | | |
| − | Sonic's collisions and interactions with these solid tiles are what make up his basic engine. They dictate how he handles floors, walls, ceilings, slopes, and loops. Because this is such a large subject, and so complex, this guide is more proximate than other Sonic Physics Guides, but I have kept speculation to a minimum.
| |
| − | | |
| − | First we will look at Sonic's method for detecting his environment, then how this environment is constructed and how Sonic handles it's complexity with such a simple system.
| |
| − | | |
| − | Note: ''While solidity tiles are used in the original games, these basic collision methods and sensor layouts will still work (with adjustments) with sprite masks, or line intersections, etc, in your own engine.''
| |
| − | | |
| − | ==Sensors==
| |
| − | The collision with solid tiles is handled using 'sensors' that surround Sonic. You can imagine these as lines which Sonic will not allow solid tiles to overlap, along the different axis. For collision with objects (which are handled quite differently) refer to [[SPG:Game_Objects|Game Objects]].
| |
| − | | |
| − | [[Image:SPGSensors.png|link=Special:FilePath/SPGSensors.png]]
| |
| − | ''An accurate approximation of the sensors''
| |
| − | | |
| − | <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> - Floor collision
| |
| − | <span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span> - Ceiling collision (only used mid-air)
| |
| − | <span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span> - Wall collision (shifting by 8px depending on certain factors, which will be explained)
| |
| − | XY - Sonic's xpos and ypos
| |
| − | | |
| − | | |
| − | Since Sonic's collision setup is symmetrical, it makes sense for the game to set up widths and heights using radius values. Sonic has separate radius values for his <span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span> sensor pair (his '''Push Radius''') which always remains the same, and for his <span style="color:#00f000; font-weight: bold;">A</span>, <span style="color:#38ffa2; font-weight: bold;">B</span>, <span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span> sensors there is a width radius (his '''Body Width Radius''') and height radius (his '''Body Height Radius''') both of which will change depending on Sonic's state.
| |
| − | | |
| − | ===Construction===
| |
| − | A width in Sonic games isn't simply 2 times the width radius.
| |
| − | | |
| − | [[Image:SPGHitBoxRadius.png]]
| |
| − | | |
| − | A radius of 8 would end up being 17 px wide rather than 16, and the sensors work in much the same way. Making his width radius of 10 become a total width of 21, '''not''' 20. This basically results in every collision mask or sensor arrangement always being an odd number in overall size. Sonic is still set 20 pixel above the ground or below a ceiling even being 39 pixels in total height as this includes his origin for every direction.
| |
| | | | |
| − | It's a matter of 1 pixel in width and height, but it could make all the difference. To avoid confusion, both measurements will be mentioned (otherwise, refer to the image examples).
| + | 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. |
| | | | |
| − | Note: '''Previous versions of this guide have incorrectly shown and stated that Sonic is 20px wide among other related issues. The images and information in this guide are now updated to be correct as of Jan '20.'''
| + | First we will look at how the environment is constructed from tiles, and then the Player's method for detecting their environment. |
| | | | |
| − | ===Sprite alignment=== | + | ==Solid Tiles== |
| − | Sonic's sprite is 1 pixel offset to the left when he faces left, which can result in him appearing to be 1px inside a tile when pushing leftwards. However to an average person playing, this won't appear to happen with most objects thanks to their hitboxes sticking out 1px further on their right and bottom (due to their origins being off-centre by 1 in X and Y). So while tiles are collided with more accurately than objects, bizarrely it will appear the opposite in-game, thanks to Sonic's sprite alignment when flipped. More about object collision in [[SPG:Game_Objects|Game Objects]].
| + | Solid Tiles are what define the terrain solidity in a stage. The shape of slopes, and the angles of them. |
| | | | |
| − | ==How Sensors Detect Solid Tiles==
| + | [[Image:SPGSolidTiles.png]] ''Solid Tiles covering the surfaces of Terrain, giving them solidity.'' |
| | | | |
| − | It's all well and good knowing that Sonic collides with solids using lines, but what's the process? First, we have to understand what Solid Tiles actually are.
| + | ===Block Grid=== |
| | + | For the purposes of this guide, the "Solid Tiles" are the actual solidity data used to define the ground shape. But the grid structure they belong to are "Blocks". Each Sonic stage essentially contains a grid of ''16''x''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 [[SPG:Solid_Tiles#Flipping_Tiles|flipping]] or [[SPG:Solid_Tiles#Flagged_Tiles|flagging]]. |
| | | | |
| − | ===Height Masks=== | + | ===Height Array=== |
| | + | Now for the Solid Tiles themselves. How is a Solid Tile set up? How is the shape of the terrain formatted? |
| | | | |
| − | When a sensor finds a tile, they return the "height" of the tile.
| + | Each Solid Tile is simply an array of ''16'' height values that can range from ''0'' to ''16'' pixels inclusive. |
| | | | |
| − | How is the height of the tile found?
| + | [[Image:SPGSolidTileHeightMasks.png]] ''Example of how many different height arrays are needed in order to account for every possible slope.'' |
| | | | |
| − | Each tile has a value associated with it that references a mask stored in memory. Each mask is simply an array of 16 height values that range from 0px ($00) to 16px ($10) and an angle value.
| + | Let's take a closer look at an example Solid Tile. |
| | | | |
| | [[Image:SPGHeightMask.PNG|link=Special:FilePath/SPGHeightMask.PNG]] | | [[Image:SPGHeightMask.PNG|link=Special:FilePath/SPGHeightMask.PNG]] |
| | | | |
| − | This height mask, for example, has the height array 0 0 1 2 2 3 4 5 5 6 7 8 9 9, and the angle 33.75° ($E8). | + | This tile's height array has the values (from left to right) |
| | + | <syntaxhighlight>0, 0, 1, 2, 2, 3, 4, 5, 5, 6, 6, 7, 8, 9, 9, 9</syntaxhighlight> |
| | + | and has the angle ''33.75° (232)''. |
| | | | |
| − | 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.
| + | Solid Tiles also have another height array (or, well, a ''width'' array) for horizontal collisions. This second array is present for all Solid Tiles, and will be used when any horizontal [[SPG:Solid_Tiles#Sensors|Sensor]] is checking the tile. |
| | | | |
| − | If the height value found is 16px ($10), that's the entire tile filled at that X position, so then the sensor has to check for another tile above the first one found, and search for that one's height value.
| + | This tile's width array has the values (from top to bottom) |
| | + | <syntaxhighlight>0, 0, 0, 0, 0, 0, 0, 3, 4, 5, 7, 9, 10, 11, 13, 14</syntaxhighlight> |
| | + | This width array represents the same slope, angle, and creates the exact same shape within the tile. |
| | | | |
| − | ===Sensor Process=== | + | ===Angles=== |
| | + | Solid Tiles contain a specific angle value which represents the angle of the slope of the surface that the Height Array creates. |
| | | | |
| − | While the sensors here are described as lines, there's actually one initial '''anchor point''' pixel when a sensor is detecting the ground around Sonic.
| + | [[Image:SPGSolidTileAngles.png]] ''Tile angles (degrees)'' |
| − | For example, imagine a single point at the bottom of Sonic's <span style="color:#00f000; font-weight: bold;">A</span> sensor, this position is the '''anchor point''' and will check for a tile.
| |
| | | | |
| − | [[Image:SPGSensorAnchors.png]] ''The white points represent the active '''anchors''' of the sensor lines.''
| + | This angle is used when the Player collides with the Solid Tile and needs to react with slope physics and to allow the Player to rotate along the terrain. |
| | | | |
| − | ====Sensor Extension==== | + | ====Flagged Tiles==== |
| − | So a sensor's '''anchor point''' has found a tile or it hasn't what if there's a tile nearby, or the tile found isn't the surface of the terrain?
| + | [[Image:SPGFlaggedSolidTiles.png]] |
| | | | |
| − | If this '''anchor point''' finds a Solid Tile, it will check up by 1 extra Solid Tile (effectively 16px up) until either there is no Solid Tile above or the Solid Tile above isn't a full block. (This check is what makes the sensor positions act as lines, and will let Sonic collide with a floor or wall even if he's already deep inside it).
| + | 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 value of the tile is ''255'', 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 right angle (0, 90, 180, or 270 degrees). Essentially, the calculation used for degrees would be: |
| | + | <syntaxhighlight>snapped_angle = (round(Ground Angle / 90) mod 4) * 90;</syntaxhighlight> |
| | | | |
| − | However, if the '''anchor point''' doesn't find a tile however, it will check down by 1 extra Solid Tile (effectively a 16px extension down) until one is found.
| + | This flag applies commonly to 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. |
| | | | |
| − | The extension will occur in the direction of the sensor, be it horizontal or vertical. | + | 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'', so is flagged despite not being a flat tile. This snaps the Player to ''90° (192)'' (aka, moving directly upwards) just as they leave the ramp. |
| | | | |
| − | Most sensors will effectively ignore this extra extension and will only re-position Sonic when he's already close enough (when the Sensor's '''anchor point''' is actually touching a tile), however Sonic's <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> sensors, while grounded, will use this extension to lock Sonic to the floor even if he's 16px above it.
| + | ===Flipping Tiles=== |
| | + | You may wonder how sloped ceilings are possible if the height array creates slopes along the tops of Solid Tiles. 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. |
| | | | |
| − | So, for all intents and purposes the lines shown are Sonic's solid areas, but it's slightly more complex internally. This method of visualising the sensors as lines is also the most accurate way to translate the solidity to other engines/frameworks which don't need to use the same specific tile calculations.
| + | The angles of flipped tiles are also adjusted to align correctly after being read. |
| | | | |
| − | ====Reaction==== | + | ===Tile Solidity=== |
| − | Once a tile has been found, it's 'height' (or position horizontally for horizontal sensors) will be returned for Sonic to use to re-position himself.
| + | Not all tiles behave the same. Some tiles are only solid from the top, some only from the sides and underneath, and some of course are solid from all directions. |
| | | | |
| − | ====Summary====
| + | Here are the colours for tile solidity that will be used on this guide: |
| − | 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, Sonic will have a ''gsp'' of 6. | + | *<span style="color:#ffffff; font-weight: bold;">⬤</span> Fully Solid (detected by all sensors) |
| | + | *<span style="color:#0071eb; font-weight: bold;">⬤</span> Top Solid only (only detected by downward facing sensors) |
| | + | *<span style="color:#00ffa8; font-weight: bold;">⬤</span> Sides & Bottom Solid only (only detected by upward and horizontal sensors) |
| | | | |
| − | [[Image:SPGSensorProcess.gif]] ''Again, of note is that while the floor sensors will not ignore the 1 tile extension when grounded, other sensors will only be "listened to" if the sensor line is already touching the tile.''
| + | What are Sensors? Well, that's up next. |
| | | | |
| − | === Floor Sensors (<span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span>) === | + | ==Sensors== |
| | | | |
| − | [[Image:SPGStandingAnimated.gif|link=Special:FilePath/SPGStandingAnimated.gif]]
| + | "Sensors" are simply checks performed by objects which look for Solid Tiles around them. |
| | | | |
| − | <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> stretch down from Sonic's ''ypos'' to his feet at ''ypos''+'''Body Height Radius'''.
| + | 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, or left, and all behave the same in their respective directions/axis. |
| | | | |
| − | ====Movement====
| + | [[Image:SPGSensorAnchors.png]] ''The white points represent the '''anchor''' positions of the Player's Sensors.'' |
| − | Typically, Sonic's '''Body Width Radius''' is 9, placing <span style="color:#00f000; font-weight: bold;">A</span> on Sonic's left side, at ''xpos''-9. While <span style="color:#38ffa2; font-weight: bold;">B</span> should be on his right, at ''xpos''+9, 19 pixels wide.
| |
| − | His '''Body Height Radius''' is usually 19, making him 39 pixels tall in total.
| |
| | | | |
| − | However while rolling or jumping, his '''Body Width Radius''' becomes 7, placing <span style="color:#00f000; font-weight: bold;">A</span> at ''xpos''-7. With <span style="color:#38ffa2; font-weight: bold;">B</span> at ''xpos''+7, 15 pixels wide. This is to ensure Sonic doesn't appear too far away from the floor at steep angles while in curled up. Crouching does not affect his '''Body Width Radius'''.
| + | 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. |
| | | | |
| − | Here's an example of that in action:
| + | The Sensor will read the height or width array of the Solid Tile in the Block it is checking. |
| | + | Which value of the array is used? For a vertical Sensor, subtract the tile's X position from the Sensor's X position. For a horizontal Sensor (using the width array), subtract the tile's Y position from the Sensor's Y position. The result is the index of the array to use. |
| | | | |
| − | [[Image:SPGWidthRadiusChange.gif|link=Special:FilePath/SPGWidthRadiusChange.gif]]
| + | So, now we know Sensors are points which look for Solid Tiles they touch, and that they can check the height or width array value of tiles at specific positions to get the floor surface position. |
| | | | |
| − | While rolling, jumping, ''or crouching'', Sonic's '''Body Height Radius''' becomes smaller at a value of 14, making him 29 pixels tall. Because of this, in the step in which Sonic rolls or jumps or otherwise becomes shorter, the engine adds 5 to his ''ypos'' so that his bottom point will remain unchanged despite him getting shorter and his center changing position. 5 also has to be subtracted from ''ypos'' when he unrolls or lands from a jump. The camera system also has to keep this offset in mind, otherwise, the view will jump when Sonic changes height.
| + | However, this is not the whole picture. If a Sensor finds an empty Block 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. |
| | | | |
| − | As described initially, all sensors will check 16px further if they don't initially find a tile. Most sensors don't use this. The difference here, is the floor sensors will use this extension to check 16px below Sonic's feet and stick to a tile while Sonic is already grounded. So if Sonic ends up slightly above the ground because of a downward slope (and he's already on the ground) this extra space checked is to keep him attached to the ground at all times, until a cliff higher than or equal to 16px turns up, or he jumps.
| + | ====Sensor Regression & Extension==== |
| | + | So when a Sensor check is performed at a Sensor's '''anchor point''' it has either found a Solid Tile in that Block, or the Block is empty. 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? |
| | | | |
| − | ====Activation====
| + | Well, this is easily solved by checking neighbouring tiles if certain conditions are met. |
| − | While grounded, the <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> sensors are always active, and are always checking for the ground beneath Sonic.
| |
| | | | |
| − | While airborne, the <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> sensors are only active when Sonic's ''ysp'' is positive (moving down) or Sonic's absolute "xsp" is larger than Sonic's absolute "ysp".
| + | 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 or width array value of a tile at the Sensor's X/Y position will be referred to as the '''detected_height'''. |
| | | | |
| − | ABSensors = ((ysp > 0) or (abs(xsp) > abs(ysp)))
| + | =====Normal===== |
| | | | |
| | + | When the '''anchor point''' finds a Solid Tile and the '''detected_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. |
| | | | |
| − | This results in Sonic's floor sensors activating when Sonic is moving fast horizontally, which helps if he is approaching a floor at a sheer horizontal angle but still moving up.
| + | Otherwise, one of the following two things will happen. |
| | | | |
| − | ====Method==== | + | =====Regression===== |
| | | | |
| − | Any time they detect a solid tile Sonic should be "popped out" to the pixel above the tile's top edge minus '''Body Height Radius'''. However, there are 2 sensors and they need to detect slopes - so greater depth will be explored after establishing where these sensors are. The following applies for flat ground while not curled up.
| + | When the '''anchor point''' finds a Solid Tile and the '''detected_height''' of the first tile is 16 (meaning the tile is completely filled in that position), it will check up by one extra Solid Tile. We'll call this the "regression" since it goes back against the Sensor direction. |
| | + | |
| | + | If a regression occurs and '''detected_height''' of the second tile is 0 (or the Block is empty), it will just default to processing the first tile, as the first tile ''must'' be the terrain surface. |
| | | | |
| − | Assuming the ground level to be at a Y position of 736 ($02E0), while standing Sonic is atop it at a ''ypos'' of 716 ($02CC), which is 20 pixels above ground level.
| + | =====Extension===== |
| | | | |
| − | =====Ledges=====
| + | When the '''anchor point''' just finds an empty Block (or the '''detected_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. |
| | | | |
| − | Sonic has to be able to run off of ledges. It would not do to just keep walking like Wile E. Coyote, not noticing that there is nothing beneath him.
| + | If an extension occurs and just finds an empty second Block (or the '''detected_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 both sensor <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> detect no solid tiles, Sonic will "fall" - a flag will be set telling the engine he is now in the air.
| |
| | | | |
| − | =====Balancing On Edges=====
| + | If a Solid Tile was found to be processed, it will calculate the distance between that '''detected_height''' and the Sensor. |
| | | | |
| − | One nice touch is that Sonic goes into a balancing animation when near to the edge of a ledge. This only happens when he is stopped (his ground speed is 0).
| + | [[Image:SPGSensorDistance.gif]] |
| | | | |
| − | How does the engine know? It is simple - any time only one of the ground sensors is activated, Sonic must be near a ledge. If <span style="color:#00f000; font-weight: bold;">A</span> is active and <span style="color:#38ffa2; font-weight: bold;">B</span> is not the ledge is to his right and vice versa.
| + | 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. |
| | | | |
| − | But if Sonic began balancing the instant one of the sensors found nothing, he would do it too "early", and it would look silly. So it only happens when only one sensor is active, and ''xpos'' is greater than the edge of the solid tile found by the active sensor.
| + | The regression & extension will occur in the direction of the Sensor, be it horizontal or vertical. So a right facing Sensor's regression would check an extra Block to the left, and extension would check an extra Block to the right. While an upward facing Sensor's regression would check an extra Block below, and extension would check an extra Block above. |
| | | | |
| − | [[Image:SPGBalancingAnimated.gif|link=Special:FilePath/SPGBalancingAnimated.gif]]
| + | 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'' Blocks (the Block the Sensor '''anchor point''' is touching plus another). |
| | | | |
| − | Assuming the right edge of the ledge to be an X position of 2655 ($0A5F), Sonic will only start to balance at an ''xpos'' of 2656 ($0A60) (edge pixel+1). He'll fall off at an ''xpos'' of 2665 ($0A69) (edge pixel+10) when both sensors find nothing.
| + | ====Reaction==== |
| − | | + | Once a final suitable tile has been found, information about the tile is returned. |
| − | In ''[[Sonic 2]]'' and ''[[Sonic CD]]'', if the ledge is the opposite direction than he is facing, he has a second balancing animation.
| |
| − | | |
| − | In ''[[Sonic 2]]'', ''[[Sonic 3]]'', and ''[[Sonic & Knuckles]]'', Sonic has yet a ''third'' balancing animation, for when he's even further out on the ledge. Assuming the same values as above, this would start when he is at an ''xpos'' of 2662 ($0A66).
| |
| − | | |
| − | '''Note:''' While balancing, certain abilities are not allowed (ducking, looking up, spindashing, etc). In Sonic 3 & Knuckles, the player is still allowed to duck and spindash (not to look up, though) when balancing on the ground but not when balancing on an object.
| |
| − | | |
| − | | |
| − | === Ceiling Sensors (<span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span>) ===
| |
| − | | |
| − | [[Image:SPGHitCeiling.gif|link=Special:FilePath/SPGHitCeiling.gif]]
| |
| − | | |
| − | Sonic's <span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span> sensors are always an exact mirror image of Sonic's floor sensors, they have the same X positions and length but are flipped upside down.
| |
| − | | |
| − | They perform in the exact same way simply up instead of down.
| |
| − | | |
| − | However, they aren't active at the same times.
| |
| − | | |
| − | ====Activation====
| |
| − | | |
| − | While grounded they are never active, and Sonic won't check for collision with solid tiles above himself while on the floor.
| |
| − | | |
| − | While airborne, Sonic's <span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span> sensors are only active when Sonic's ''ysp'' is negative (moving up) or Sonic's absolute "xsp" is larger than Sonic's absolute "ysp".
| |
| − | | |
| − | CDSensors = ((ysp < 0) or (abs(xsp) > abs(ysp)))
| |
| − | | |
| − | | |
| − | This results in Sonic's ceiling sensors activating when Sonic is moving fast horizontally, which helps if he is approaching a ceiling at a sheer horizontal angle but still moving down.
| |
| − | | |
| − | ====Method====
| |
| − | | |
| − | Sonic will detect ceilings and be pushed out of them whether he is moving up or down, unlike floors which are only detected when moving down. It ''is'' possible to hit a "ceiling" (which is just the bottom side of a block) while moving down - by pressing toward a wall with a gap in it, or jumping toward the side of an upper curve both with a high absolute ''xsp''.
| |
| − | | |
| − | | |
| − | === Wall Sensors (<span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span>) ===
| |
| − | | |
| − | [[Image:SPGPushingAnimated.gif|link=Special:FilePath/SPGPushingAnimated.gif]]
| |
| − | | |
| − | <span style="color:#ff38ff; font-weight: bold;">E</span> spans from Sonic's ''xpos'' to his left at ''xpos''-'''Push Radius''', while <span style="color:#ff5454; font-weight: bold;">F</span> spans from Sonic's ''xpos'' to his right at ''xpos''+'''Push Radius'''.
| |
| − | | |
| − | ====Movement====
| |
| − | | |
| − | '''Push Radius''' is always 10, stretching <span style="color:#00f000; font-weight: bold;">E</span> to Sonic's left side, at ''xpos''-10. While <span style="color:#38ffa2; font-weight: bold;">F</span> stretches to his right, at ''xpos''+10, giving Sonic a total width of 21 pixels when pushing.
| |
| − | | |
| − | Sensors <span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span> Spend most of their time at Sonic's ''ypos'' however while Sonic's ''ang'' is 0 (on totally flat ground) both wall sensors will move to his ''ypos''+8 so that he can push against low steps and not just snap up ontop of them.
| |
| − | | |
| − | The horizontal sensor lines are always positioned at ''ypos'' while airborne.
| |
| − | | |
| − | ====Activation==== | |
| − | | |
| − | When grounded, Sensors <span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span> only activate when Sonic is walking in that direction. For example, while standing still Sonic isn't checking with his wall sensors at all, but while ''gsp'' is positive, Sonic's <span style="color:#ff38ff; font-weight: bold;">E</span> sensor is inactive, and while ''gsp'' is negative, Sonic's <span style="color:#ff5454; font-weight: bold;">F</span> sensor is inactive.
| |
| − | | |
| − | However this is not always the case, both wall sensors simply don't appear when Sonic's ''ang'' is outside of a 0 to 90 and 270 to 360 (or simply -90 to 90) degree range, meaning when you running around a loop, the wall sensors will vanish for the top half of the loop. In S3K however these sensors will also appear when Sonic's 'ang' is a multiple of 90 in addition to the angle range.
| |
| − | | |
| − | =====While airborne =====
| |
| − | | |
| − | Sensor <span style="color:#ff38ff; font-weight: bold;">E</span> is not active when Sonic's ''xsp'' is greater than his absolute ''ysp'', so basically it only deactivates if we are moving very fast right, and not too fast up or down.
| |
| − | | |
| − | Sensor <span style="color:#ff5454; font-weight: bold;">F</span> is not active when Sonic's ''xsp'' is less than the negative of his absolute ''ysp'', so basically it only deactivates if we are moving very fast left, and not too fast up or down.
| |
| − | | |
| − | ESensor = !(xsp > abs(ysp))
| |
| − | FSensor = !(-xsp > abs(ysp))
| |
| − | | |
| − | | |
| − | This results in both Sonic's wall sensors activating when Sonic is moving fast vertically, which helps if he is approaching a wall to the right at a sheer angle but still moving left, or the opposite.
| |
| − | | |
| − | ====Method====
| |
| − | | |
| − | Assuming the wall's left side to be at an X position of 704 ($02C0), Sonic cannot get closer than an ''xpos'' of 693 ($02B5). Assuming the wall's right side to be at an X position of 831 ($033F), Sonic cannot get closer than an ''xpos'' of 842 ($034A). Thus both sensor lines combined should be 21 pixels wide, stretching from Sonic's ''xpos''-10 to ''xpos''+10.
| |
| − | | |
| − | Any time it detects a solid tile, Sonic should be "popped out", set to the edge of the tile minus (or plus) 11, and his ground speed set to 0. (He cannot be popped out by only 10, because then a point at ''xpos''+10 would still lie within the edge pixel of the tile. This would register a continuous collision, and he would stick to the wall.) This will also set his '''gsp''' to 0 if he is moving in the direction of the wall, not away from it. If it were otherwise, he would stick to walls if he tried to move away.
| |
| − | | |
| − | Though the tile's edge minus Sonic's ''xpos'' might be 11, there are 10 free pixels between Sonic's ''xpos'' and the tile's edge. The eleventh pixel away is the tile's edge itself. This would be the same for a tile on the left. So Sonic is effectively 21 pixels wide when including ''xpos''.
| |
| − | | |
| − | You may remember that sensors <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> are only 19 pixels apart but Sonic is 21 pixels wide when pushing into walls. This means that Sonic is skinnier by 2 pixels when running off of ledges than when bumping into walls.
| |
| − | | |
| − | ===Summary===
| |
| − | | |
| − | Here's a handmade visualisation of how sensors interact with solid tiles (here highlighted in bright blue, green, and cyan). You can notice how the sensor lines are pushing Sonic from the ground tiles, and is overall rather simple. The <span style="color:#ff38ff; font-weight: bold;">E</span> and <span style="color:#ff5454; font-weight: bold;">F</span> sensors lower when on flat ground. You can also notice the sensor lines snap in 90 degree rotations resulting in four modes, this will be covered further down the guide.
| |
| − | | |
| − | [[Image:SPGCollisionDemo.gif|link=Special:FilePath/SPGCollisionDemo.gif]] ''Keep in mind, while on the ground the upper <span style="color:#00aeef; font-weight: bold;">C</span> and <span style="color:#fff238; font-weight: bold;">D</span> sensors would not exist, and while gsp is positive the left wall sensor would also not appear. These sensors are only included for illustration purposes.''
| |
| − | | |
| − | ====Bugs Using This Method====
| |
| − | | |
| − | Unfortunately, there are a couple of annoying bugs in the original engine because of this method.
| |
| − | | |
| − | If Sonic stands on a slanted ledge, one sensor will find no tile and return a height of foot level. This causes Sonic to be set to the wrong position.
| |
| − | | |
| − | [[Image:SPGSlopeBug1Animated.gif|link=Special:FilePath/SPGSlopeBug1Animated.gif]]
| |
| − | | |
| − | Sonic raises up with sensor <span style="color:#38ffa2; font-weight: bold;">B</span> sensor as he moves right. When <span style="color:#38ffa2; font-weight: bold;">B</span> drops off the ledge, Sonic defaults to the level of sensor <span style="color:#00f000; font-weight: bold;">A</span>. Then he raises up with sensor <span style="color:#00f000; font-weight: bold;">A</span> as he moves further right. So he will move up, drop down, and move up again as he runs off the ledge.
| |
| − | | |
| − | There are only a few areas where this is noticeable, but it applies to all Mega Drive titles and is pretty tacky.
| |
| − | | |
| − | The second form of it occurs when two opposing ramp tiles abut each other, as in some of the low hills in [[Green Hill Zone]] and [[Marble Zone]].
| |
| − | | |
| − | [[Image:SPGSlopeBug2Animated.gif|link=Special:FilePath/SPGSlopeBug2Animated.gif]]
| |
| − | | |
| − | Sensor <span style="color:#38ffa2; font-weight: bold;">B</span> starts climbing down the ramp on the right, but Sonic still defaults to the level of the previous ramp found by sensor <span style="color:#00f000; font-weight: bold;">A</span>. Because these ramps are usually shallow, this only causes him to dip down in the middle by about 1 pixel.
| |
| − | | |
| − | But that is not all. Because the highest sensor is the one Sonic gets the angle from, even though it looks like he should be considered to be at the angle of the ramp on the right (because he is closer to it), he will still have the angle of the ramp on the left. When you jump, he will jump at that angle, moving backward, not forward like you would expect.
| |
| − | | |
| − | ===Moving At Angles===
| |
| − | | |
| − | Well, that is all very well and good for having Sonic move smoothly over terrain with different heights, but that is not all there is to the engine. Sonic's speed has to be attenuated by angled ground in order to be realistic.
| |
| − | | |
| − | There are two ways in which Sonic's speed is affected on angles. The first will make sure that he does not traverse a hill in the same amount of time as walking over flat ground of an equal width. The second will slow him down when going uphill and speed him up when going downhill. Let's look at each of these in turn.
| |
| − | | |
| − | ====The Three Speed Variables====
| |
| − | | |
| − | If Sonic were a simple platformer that required nothing but blocks, you would only need two speed variables: X speed (''xsp'') and Y speed (''xsp''), the horizontal and vertical components of Sonic's velocity. Acceleration (''acc''), deceleration (''dec''), and friction (''frc'') are added to ''xsp''; jump/bounce velocity and gravity (''grv'') are added to ''ysp'' (when Sonic is in the air).
| |
| − | | |
| − | But when slopes are involved, while Sonic moves along a slope, he's moving both horizontally and vertically. This means that both ''xsp'' and ''xsp'' have a non-zero value. Simply adding ''acc'', ''dec'', or ''frc'' to ''xsp'' no longer works; imagine Sonic was trying to run up a wall - adding to his horizontal speed would be useless because he needs to move upward.
| |
| − | | |
| − | The trick is to employ a third speed variable (as the original engine does), so let's call it Ground speed (''gsp''). This is the speed of Sonic along the ground, disregarding ''ang'' altogether. ''acc'', ''dec'', and ''frc'' are applied to ''gsp'', not ''xsp'' or ''ysp''.
| |
| − | | |
| − | While on the ground, ''xsp'' and ''xsp'' are derived from ''gsp'' every step before Sonic is moved. Perhaps a pseudo-code example is in order:
| |
| − | | |
| − | xsp = gsp*cos(angle);
| |
| − | ysp = gsp*-sin(angle);
| |
| − |
| |
| − | xpos += xsp;
| |
| − | ypos += ysp;
| |
| − | | |
| − | No matter what happens to the ''ang'', ''gsp'' is preserved, so the engine always knows what speed Sonic is "really" moving at.
| |
| − | | |
| − | ====Slope Factor====
| |
| − | | |
| − | By this point, Sonic should be able to handle any hills with an accurate velocity but he still needs to slow down when going uphill and speed up when going downhill.
| |
| − | | |
| − | Fortunately, this is simple to achieve - with something called the Slope Factor (''slope''). Just subtract ''slope''*sin(''ang'') from ''gsp'' at the beginning of every step.
| |
| − | | |
| − | gsp -= slope*sin(ang);
| |
| − | | |
| − | The value of ''slope'' is always ''slp'' when running, but not so when rolling. When Sonic is rolling uphill (the sign of ''gsp'' is equal to the sign of sin(''ang'')), ''slope'' is ''slprollup'' ($001E). When Sonic is rolling downhill (the sign of ''gsp'' is '''not''' equal to the sign of sin(''ang'')), ''slope'' is ''slprolldown'' ($0050).
| |
| − | | |
| − | '''Note:''' In Sonic 1, it appears that ''slope'' doesn't get added if Sonic is stopped and in his standing/waiting cycle. But in Sonic 3 & Knuckles, ''slope'' seems to be added even then, so that Sonic can't stand on steep slopes - they will force him to walk them down.
| |
| − | | |
| − | ===Jumping At Angles===
| |
| − | | |
| − | Jumping is also affected by the angle Sonic is at when he does it. He can't simply set ''ysp'' to negative ''jmp'' - he needs to jump away from the angle he's standing on. Instead, both ''xsp'' and ''ysp'' must have ''jmp'' subtracted from them, using cos() and sin() to get the right values.
| |
| − | | |
| − | More pseudo-code:
| |
| − | | |
| − | xsp -= jmp*sin(angle);
| |
| − | ysp -= jmp*cos(angle);
| |
| − | | |
| − | Notice how the jump values are subtracted from the ''xsp'' and ''ysp''. This means his speeds on the ground are preserved, meaning running up fast on a steep hill and jumping gives you the jump speeds and the speeds you had on the hill, resulting in a very high jump.
| |
| − | | |
| − | ==Switching Mode==
| |
| − | | |
| − | So Sonic can run over hills and ramps and ledges, and all that is great. But it is ''still'' not enough. He cannot make his way from the ground to walls and ceilings without more work.
| |
| − | | |
| − | Why not? Well, because sensor <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> check straight downward, finding the height of the ground. There is just no way they can handle the transition to walls when everything is built for moving straight up and down on the Y-axis.
| |
| − | | |
| − | How can we solve this? By using four different modes of movement. This will take a little explaining.
| |
| − | | |
| − | ===The Four Modes===
| |
| − | | |
| − | It seems pretty reasonable to assume that, because Sonic can traverse ground in 360 degrees, the engine handles all 360 degrees in much the same way. But, in fact, the engine splits the angles into four quadrants, greatly simplifying things.
| |
| − | | |
| − | To better understand what I am talking about, imagine a simpler platformer without full loops, just a few low hills and ramps. All the character would need to do is, after moving horizontally, move up or down until they met the level of the floor. The angle of the floor would then be measured. The angle would be used to attenuate ''gsp'', but nothing more. The character would still always move horizontally and move straight up and down to adhere to floor level.
| |
| − | | |
| − | This is much like how Sonic does things. Only, when ''ang'' gets too steep, Sonic switches "quadrant", moving from Floor mode to Right Wall mode (to Ceiling mode, to Left Wall mode, and back around to Floor mode, etc). At any one time, in any one mode, Sonic behaves like a simpler platformer. The magic happens by combining all four modes, and cleverly switching between them smoothly.
| |
| − | | |
| − | So how and when does Sonic switch mode?
| |
| − | | |
| − | When in Floor mode, and ''ang'' is steeper than 45° ($E0), the engine switches into Right Wall mode. Everything is basically the same, only the sensors check to the right instead of downward, and Sonic is moved to "floor" level horizontally instead of vertically.
| |
| − | | |
| − | Now that he's in Right Wall mode, if ''ang'' is shallower than 45° ($E0), the engine switches back into Floor mode.
| |
| − | | |
| − | The other transitions work in exactly the same way, with the switch angles relative to the current mode.
| |
| − | | |
| − | A quick calculation can be made using ''ang'' of the floor, which will place Sonic in the correct mode:
| |
| − | | |
| − | mode = round(angle/90) % 4;
| |
| − | | |
| − | | |
| − | This would return Sonic's Floor mode at 0, Right Wall at 1, Ceiling at 2, and Left Wall at 3.
| |
| − | | |
| − | You might rightly ask where the ground sensors are when in Right Wall mode. They're in exactly the same place, only rotated 90 degrees. Sensor <span style="color:#00f000; font-weight: bold;">A</span> is now at Sonic's ''ypos''+9 instead of ''xpos''-9. Sensor <span style="color:#38ffa2; font-weight: bold;">B</span> is now at Sonic's ''ypos''-9, instead of ''xpos''+9. Instead of vertical sensor lines, they are now horizontal, stretching 16 pixels beyond his foot level (which is now 20 pixels "below" him, at ''xpos''+20).
| |
| − | | |
| − | Yes, because the sensors move so far, it is possible for Sonic to be "popped" out to a new position in the step in which he switches mode. However, this is hardly ever more than a few pixels and really isn't noticeable at all during normal play. To adjust for this in a new engine, an alternative method to switch mode would be to check for solid ground using a 90 degree rotated mask. For example, standing upright on flat ground, the left side would check rotated 90 degrees for steep slopes to switch to Left Wall Mode, and the right would check rotated -90 degrees for steep slopes to switch to Right Wall Mode. Only the lower ground sensor of the rotated mask would need to check for ground. This would have to exclude walls so Sonic doesn't begin walking on a wall when he gets near one, but would mean Sonic switched mode sooner on a slope which means less "popping".
| |
| − | | |
| − | One more thing: I said that solid tiles were made of height arrays. Operative word: ''height''. How do they work when in Right Wall mode? Well, rather gobsmackingly, it turns out that in the original engine, each solid tile has ''two'' complementary height arrays, one used for when moving horizontally, the other for when moving vertically.
| |
| − | | |
| − | What about Left Wall and Ceiling mode? Wouldn't there need to be ''four'' height arrays? No, because tiles of those shapes simply use normal height arrays, just inverted. When in Ceiling mode, Sonic knows that the height value found should be used to move him down and not up.
| |
| − | | |
| − | With these four modes, Sonic can go over all sorts of shapes. Inner curves, outer curves, you name them. Here are some example images with their angle values to help give you some idea of what I've been talking about:
| |
| − | | |
| − | [[Image:SPGInnerCurve.PNG|link=Special:FilePath/SPGInnerCurve.PNG]] [[Image:SPGInnerCurveChart.PNG|link=Special:FilePath/SPGInnerCurveChart.PNG]]
| |
| − | | |
| − | [[Image:SPGOuterCurve.PNG|link=Special:FilePath/SPGOuterCurve.PNG]] [[Image:SPGOuterCurveChart.PNG|link=Special:FilePath/SPGOuterCurveChart.PNG]]
| |
| − | | |
| − | ===Falling and Sliding Off Of Walls And Ceilings===
| |
| − | | |
| − | When in Right Wall, Left Wall, or Ceiling mode and Sonic's ''ang'' is between 90 and 270, Sonic will fall any time absolute ''gsp'' falls below ''fall'' ($0280) (''gsp'' is set to 0 at this time, but ''xsp'' and ''ysp'' are unaffected, so Sonic will continue his trajectory through the air). This happens even if there is ground beneath him. If Sonic is in Right Wall, Left Wall, or Ceiling Mode but Sonic's ''ang'' is not between 90 and 270 then the horizontal control lock timer described below will still be set to 30 but Sonic will not enter a falling state remaining in his current state.
| |
| − | | |
| − | ====Horizontal Control Lock====
| |
| − | | |
| − | When Sonic falls or slides off in the manner described above, the [[SPG:Springs and Things#Horizontal Control Lock|horizontal control lock]] timer is set to 30 ($1E) (it won't begin to count down until Sonic lands back on the ground). While this timer is non-zero and Sonic is on the ground, it prevents the player from adjusting Sonic's speed with the left or right buttons. The timer counts down by one every step, so the lock lasts about half a second. During this time only ''slp'' and the speed Sonic fell back on the ground with is in effect, so Sonic will slip back down the slope.
| |
| − | | |
| − | if (abs(gsp) < 2.5 && floor_mode != 0)
| |
| − | {
| |
| − | if (angle >= 90 && angle <= 270)
| |
| − | {
| |
| − | floor_mode = 0;
| |
| − | gsp = 0;
| |
| − | }
| |
| − | horizontal_lock_timer = 30;
| |
| − | }
| |
| − | | |
| − | ==The Air State==
| |
| − | | |
| − | Any time Sonic is in the air, he doesn't have to worry about angles, ''gsp'', ''slp'', or any of that jazz. All he has to do is move using ''xsp'' and ''ysp'' until he detects the ground, at which point he re-enters the ground state.
| |
| | | | |
| − | ===Jumping "Through" Floors===
| + | 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 |
| | | | |
| − | There are some ledges that Sonic can jump up "through". These are often in the hilly, green zones such as [[Green Hill Zone]], [[Emerald Hill Zone]], [[Palmtree Panic Zone]], and so on. The solid tiles that make up these ledges are flagged by the engine as being a certain type that should only be detected by Sonic's <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> sensors. They are ignored entirely by C and D as well as the horizontal sensor line. Finally, sensor <span style="color:#00f000; font-weight: bold;">A</span> and <span style="color:#38ffa2; font-weight: bold;">B</span> (mostly) only detect the floor when Sonic is moving downwards (but always while on the ground). So with a slightly shorter jump, you will see Sonic 'pop' upwards onto a jump through surface once he begins to fall.
| + | =====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. |
| | | | |
| − | ===Reacquisition Of The Ground===
| + | The distance can either be ''0'', negative, or positive. |
| − | Both ''xsp'' and ''ysp'' are derived from ''gsp'' while Sonic is on the ground. When he falls or otherwise leaves the ground, ''xsp'' and ''ysp'' are already the proper values for him to continue his trajectory through the air. But when Sonic lands back on the ground, ''gsp'' must be calculated from the ''xsp'' and ''ysp'' that he has when it happens.
| |
| − | You might think that they would use cos() and sin() to get an accurate value, but that is not the case. In fact, something much more basic happens, and it is different when hitting into a curved ceiling as opposed to landing on a curved floor, so I will cover them separately.
| |
| | | | |
| − | As you land the angle of the ground you touch is read (''ang'').
| + | 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. This is the potentially "no-tile-found" distance range. |
| − | The following covers the angle (''ang'') of the ground (floor or ceiling) that Sonic touches as he lands, and only happens the frame when he lands when changing from in air to on ground.
| |
| | | | |
| − | ====When Falling Downward====
| + | *''Note: It doesn't necessarily mean no tile has been found if the distance is in this range, but if no tile was found the distance will definitely be within this range so the game typically chooses to treat it as such just in case.'' |
| − | [[Image:SPGLandFloor.png|link=Special:FilePath/SPGLandFloor.png]]
| |
| | | | |
| − | '''Shallow:'''
| + | 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. |
| − | When ''ang'' is in the range of 22.5°~0° ($F0~$FF) (and their mirror images, 360°~337.5° ($00~$0F)), ''gsp'' is set to the value of ''xsp''.
| |
| | | | |
| − | '''Half Steep:'''
| + | *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). |
| − | When ''ang'' is in the range of 22.5°~45° ($E0~$EF) (and mirrored 337.5°~315° ($10~$1F)), ''gsp'' is set to ''xsp'' but only if the absolute of ''xsp'' is greater than ''ysp''. Otherwise, ''gsp'' is set to ''ysp''*0.5*-sign(sin(''ang'')).
| |
| | | | |
| − | '''Full Steep:'''
| + | *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. |
| − | When ''ang'' is in the range of 45°~90° ($C0~$DF) (and mirrored 315°~270° ($20~$3F)), ''gsp'' is set to ''xsp'' but only if the absolute of ''xsp'' is greater than ''ysp''. Otherwise, ''gsp'' is set to ''ysp''*-sign(sin(''ang'')).
| |
| | | | |
| − | ====When Going Upward====
| + | *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. |
| − | [[Image:SPGLandCeiling.png|link=Special:FilePath/SPGLandCeiling.png]]
| |
| | | | |
| − | '''Slope:'''
| + | 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. |
| − | When the ceiling ''ang'' detected is in the range of 135°~90° ($A0~$BF) (and mirrored 270°~225° ($40~$5F)), Sonic reattaches to the ceiling and ''gsp'' is set to ''ysp''*-sign(sin(''ang'')).
| |
| | | | |
| − | Note: This does not allow you to connect to a sloped ceiling and follow it downwards when you are moving horizontally in the air. One example of this is the secret route in CPZ act 2. In your engine, you may wish to use a method similar to when going downwards. If absolute ''xsp'' is greater than negative ''ysp'', set ''gsp'' to negative ''xsp''. Otherwise, use the calculation above.
| + | Of course, as stated, this distance can be representative of any 4 directions, depending on the Sensor's own angle. |
| | | | |
| − | '''Ceiling:''' | + | ====Typical Sensor Usage==== |
| − | When the ceiling ''ang'' is in the range of 225°~135° ($60~$9F), Sonic hits his head like with any ceiling, and doesn't reattach to it. ''ysp'' is set to 0, and ''xsp'' is unaffected.
| + | Sensors are utilised by many different objects, including the Player, to align themselves or "collide" with Solid Tiles. A Sensor will typically be cast with an anchor positioned at the edge of the object, pointing outwards. For example, positioned at the right of an object at <code>'''''X Position''''' + '''''Width Radius'''''</code> pointing right, or positioned at the bottom of an object at <code>'''''Y Position''''' + '''''Height Radius'''''</code> pointing down. |
| | | | |
| | + | Most objects will only use 1 or 2 Sensors, usually pointing down looking for the floor, though some will also use additional Sensors to check for walls. The Player object is more complex and can sometimes use up to 5 Sensors at once depending on their state. How the Player uses Sensors is described in [[SPG:Slope_Collision#The_Player.27s_Sensors|Slope Collision]]. |
| | | | |
| − | ==Reference: Converting Hex Angles==
| + | In the example of a Sensor at the bottom, if terrain is found nearby the distance found from this Sensor can be used to reposition the object to align perfectly with the floor. For example if the Sensor returned a distance of ''-10'', the Sensor is 10 pixels inside of the Terrain, and the object would simply have to add ''-10'' to their '''''Y Position''''' to align perfectly with the surface. |
| | + | Objects typically won't react to positive distances where the Sensor is outside of the terrain (but not always, typically positive Sensor distances are used for alignment while an object is already on the ground to ensure they remain "stuck"). |
| | | | |
| − | The Mega Drive games use angles in hex, $00 through $FF, meaning that there are only 256 divisions of a circle, not 360 like we're used to. Worse, the direction is anti-clockwise compared to other languages like GML, so $20 isn't 45° like it should be - it's 315°.
| + | =====Distance Rejection===== |
| | + | Objects will reject distances too "large" in either direction (positive or negative). |
| | | | |
| − | In order to convert the original hex angles into angles you can use in GML, use this calculation (rendered here in pseudo-code):
| + | When casting Sensors, objects check the returned distances it accepts for collision. For example, checking if a distance is <code>>= 16</code> or <code><= -16</code> and if it is, not colliding. This will filter out potentially "no-tile-found" distances. This avoids a need for the game to remember if a tile was found after the Sensor was cast, it can just remember the distance value. Though typically the game opts for a distance of ''14'' as the limit (<code>< -14</code> or <code>> 14</code>) as this usually means either the surface of the Solid Tile is too far away to matter anyway. |
| | | | |
| − | return (256-hex_angle)*1.40625;
| + | ====Visual Depiction==== |
| | + | Sensors will be drawn from the Sensor anchor, extending towards the centre of the object. This demonstrates the direction of the Sensor, and also, given the typical use of Sensors, the approximate "solid" areas of the object using the Sensor. |
| | | | |
| − | ==Notes==
| + | You can imagine it vaguely like so - if the very edge pixels of the surface of the ground is within these lines, the object would collide and be pushed out of the Solid Tile. 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... and sometimes objects will align themselves even when the Sensor returns positive distances and aren't even touching the Solid Tile... and objects will reject all sorts of different varying distances Sensors return depending on what the Sensor is being used for... This would be impossible to accurately draw over the Player while keeping things understandable and clear. This visualisation is a simplified and rough estimation. |
| − | * Sonic can only brake ("screech to a halt") in Floor mode.
| |
| − | * Sonic cannot jump when there is a low ceiling above him. If there is a collision detected with a sensor line stretching from Sonic's ''xpos''-9 to ''xpos''+9, at ''ypos''-25, Sonic won't bother jumping at all.
| |
| | | | |
| | + | Just be aware that the line based depictions are for simple illustration purposes only and the endpoints of the lines are the active Sensor anchor positions (which always behave as described). |
| | | | |
| | [[Category:Sonic Physics Guide]] | | [[Category:Sonic Physics Guide]] |
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).
- This page is essentially part 1 of 2. This details what Solid Tiles are and how they are used directly. For part 2, detailing how Solid Tiles and collision layers are used to create anything from simple slopes all the way to bigger Sonic set-pieces like loops, go to Solid Terrain.
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.
Solid Tiles covering the surfaces of Terrain, giving them solidity.
Block Grid
For the purposes of this guide, the "Solid Tiles" are the actual solidity data used to define the ground shape. But the grid structure they belong to are "Blocks". Each Sonic stage essentially contains a grid of 16x16px 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 0 to 16 pixels inclusive.
Example of how many different height arrays are needed in order to account for every possible slope.
Let's take a closer look at an example Solid Tile.
This tile's height array has the values (from left to right)
0, 0, 1, 2, 2, 3, 4, 5, 5, 6, 6, 7, 8, 9, 9, 9
and has the angle 33.75° (232).
Solid Tiles also have another height array (or, well, a width array) for horizontal collisions. This second array is present for all Solid Tiles, and will be used when any horizontal Sensor is checking the tile.
This tile's width array has the values (from top to bottom)
0, 0, 0, 0, 0, 0, 0, 3, 4, 5, 7, 9, 10, 11, 13, 14
This width array represents the same slope, angle, and creates the exact same shape within the tile.
Angles
Solid Tiles contain a specific angle value which represents the angle of the slope of the surface that the Height Array creates.
Tile angles (degrees)
This angle is used when the Player collides with the Solid Tile and needs to react with slope physics and to allow the Player to rotate along the terrain.
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 value of the tile is 255, 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 right angle (0, 90, 180, or 270 degrees). Essentially, the calculation used for degrees would be:
snapped_angle = (round(Ground Angle / 90) mod 4) * 90;
This flag applies commonly to 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, so is flagged despite not being a flat tile. This snaps the Player to 90° (192) (aka, moving directly upwards) just as they leave the ramp.
Flipping Tiles
You may wonder how sloped ceilings are possible if the height array creates slopes along the tops of Solid Tiles. 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 to align correctly after being read.
Tile Solidity
Not all tiles behave the same. Some tiles are only solid from the top, some only from the sides and underneath, and some of course are solid from all directions.
Here are the colours for tile solidity that will be used on this guide:
- ⬤ Fully Solid (detected by all sensors)
- ⬤ Top Solid only (only detected by downward facing sensors)
- ⬤ Sides & Bottom Solid only (only detected by upward and horizontal sensors)
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, or left, and all behave the same in their respective directions/axis.
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.
The Sensor will read the height or width array of the Solid Tile in the Block it is checking.
Which value of the array is used? For a vertical Sensor, subtract the tile's X position from the Sensor's X position. For a horizontal Sensor (using the width array), subtract the tile's Y position from the Sensor's Y position. The result is the index of the array to use.
So, now we know Sensors are points which look for Solid Tiles they touch, and that they can check the height or width array value of tiles at specific positions to get the floor surface position.
However, this is not the whole picture. If a Sensor finds an empty Block 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 in that Block, or the Block is empty. 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 or width array value of a tile at the Sensor's X/Y position will be referred to as the detected_height.
Normal
When the anchor point finds a Solid Tile and the detected_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 two things will happen.
Regression
When the anchor point finds a Solid Tile and the detected_height of the first tile is 16 (meaning the tile is completely filled in that position), it will check up by one extra Solid Tile. We'll call this the "regression" since it goes back against the Sensor direction.
If a regression occurs and detected_height of the second tile is 0 (or the Block 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 Block (or the detected_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 Block (or the detected_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 detected_height and the Sensor.
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. So a right facing Sensor's regression would check an extra Block to the left, and extension would check an extra Block to the right. While an upward facing Sensor's regression would check an extra Block below, and extension would check an extra Block 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 Blocks (the Block 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. This is the potentially "no-tile-found" distance range.
- Note: It doesn't necessarily mean no tile has been found if the distance is in this range, but if no tile was found the distance will definitely be within this range so the game typically chooses to treat it as such just in case.
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.
- 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.
Typical Sensor Usage
Sensors are utilised by many different objects, including the Player, to align themselves or "collide" with Solid Tiles. A Sensor will typically be cast with an anchor positioned at the edge of the object, pointing outwards. For example, positioned at the right of an object at X Position + Width Radius pointing right, or positioned at the bottom of an object at Y Position + Height Radius pointing down.
Most objects will only use 1 or 2 Sensors, usually pointing down looking for the floor, though some will also use additional Sensors to check for walls. The Player object is more complex and can sometimes use up to 5 Sensors at once depending on their state. How the Player uses Sensors is described in Slope Collision.
In the example of a Sensor at the bottom, if terrain is found nearby the distance found from this Sensor can be used to reposition the object to align perfectly with the floor. For example if the Sensor returned a distance of -10, the Sensor is 10 pixels inside of the Terrain, and the object would simply have to add -10 to their Y Position to align perfectly with the surface.
Objects typically won't react to positive distances where the Sensor is outside of the terrain (but not always, typically positive Sensor distances are used for alignment while an object is already on the ground to ensure they remain "stuck").
Distance Rejection
Objects will reject distances too "large" in either direction (positive or negative).
When casting Sensors, objects check the returned distances it accepts for collision. For example, checking if a distance is >= 16 or <= -16 and if it is, not colliding. This will filter out potentially "no-tile-found" distances. This avoids a need for the game to remember if a tile was found after the Sensor was cast, it can just remember the distance value. Though typically the game opts for a distance of 14 as the limit (< -14 or > 14) as this usually means either the surface of the Solid Tile is too far away to matter anyway.
Visual Depiction
Sensors will be drawn from the Sensor anchor, extending towards the centre of the object. This demonstrates the direction of the Sensor, and also, given the typical use of Sensors, the approximate "solid" areas of the object using the Sensor.
You can imagine it vaguely like so - if the very edge pixels of the surface of the ground is within these lines, the object would collide and be pushed out of the Solid Tile. 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... and sometimes objects will align themselves even when the Sensor returns positive distances and aren't even touching the Solid Tile... and objects will reject all sorts of different varying distances Sensors return depending on what the Sensor is being used for... This would be impossible to accurately draw over the Player while keeping things understandable and clear. This visualisation is a simplified and rough estimation.
Just be aware that the line based depictions are for simple illustration purposes only and the endpoints of the lines are the active Sensor anchor positions (which always behave as described).
Solid Tiles covering the surfaces of Terrain, giving them solidity.
Example of how many different height arrays are needed in order to account for every possible slope.
Tile angles (degrees)
The white points represent the anchor positions of the Player's Sensors.
