SPG:Basics

Sonic Physics Guide
Basics Positions And Speeds Angles Variables Calculations (Technical) Pixel and Subpixel Hex Angles Characters Sonic Tails Knuckles
Collision
Solid Tiles (Terrain Part 1) Sensors Solid Terrain (Terrain Part 2) Layers Loops Slope Collision (Slopes Part 1) The Player's Sensors While Grounded 360 Degree Collision While Airborne Hitboxes The Player's Hitbox Trigger Areas Solid Objects Solid Objects Sloped Objects Jump Through Platforms Pushable Blocks Item Monitor
Physics
Slope Physics (Slopes Part 2) Moving Along Slopes 360 Degree Movement Falling and Slipping Down Slopes Landing On The Ground Air State Running Jumping Rolling Getting Hit Rebound Underwater Air Physics Super Speeds
Gameplay
Main Game Loop Game Objects Game Enemies Badniks Bosses Ring Loss Special Abilities Spindash Super Peel Out Drop Dash Insta-Shield Flying Gliding Climbing Elemental Shields Flame Shield Bubble Shield Lightning Shield Player 2 Player 2 CPU Respawning Special Stages Rotating Maze
Presentation
Camera Animations Animation System Variable Speed Animation Timings Normal Animation Timings Animation Rules
Special
Overlay Scripts Sonic 1 Overlay Sonic 2 Overlay

Notes:

• Research applies to all four of the Mega Drive games, and Sonic CD.

Introduction

The aim of this guide is to accurately describe the mechanics of classic Sonic games, while explaining the concepts well enough to allow for different ways to implement the same ideas. All that is described can be implemented in many different ways with the same or very similar results, and nothing needs to be done the exact way the Genesis hardware did.

Before we dive into how the game works, it is first important to know some basic attributes about how the games are structured which will apply to multiple aspects throughout this guide. This is relevant mostly for those looking for extremely close accuracy, and to provide context for some of the game's more subtle behaviour involving collision or motion.

Objects

Objects are the moving building blocks of each Sonic game (aside from the Terrain Tiles or Solid Tiles which physically make up the Zones and Acts themselves). Characters are objects, Badniks are objects, Bosses are constructed from multiple objects, Game Objects such as Springs or Item Monitors are objects, and so on.

Variables

The following object variables/constants will be referenced frequently in this guide.

//General Object Variables/Attributes
X Position: The X-coordinate of the object's centre.
Y Position: The Y-coordinate of the object's centre.
X Speed: The speed at which the object is moving horizontally.
Y Speed: The speed at which the object is moving vertically.
Ground Speed: The speed at which the object is moving on the ground.
Ground Angle: The object's angle on the ground.
Width Radius: The object's width from the origin pixel left and right.
Height Radius: The object's height from the origin pixel up and down.

//The Player's Variables/Constants
Push Radius: Sonic's width from the origin pixel left and right (for pushing).
Slope Factor: The current slope factor value being used.

Set up

Each game object follows the same or similar conventions. They all have X and Y positions, X and Y speeds, a Width Radius, a Height Radius, animation variables, an angle, and more.

Typically the Width and Height Radius of an object describes it's solid size. So it's the box size the Player can push against, or how big it is when touching solid tiles if it can move around. Or both, as the case may be.

Sizes

Objects use 2 values to define their size for collision. A Width Radius, and a Height Radius. These are centred outward on the object's origin, forming a box around it. In a game with small sprites and pixel art, a pixel difference with worth acknowledging. A size in Sonic games isn't simply 2 times the radius.

A radius of 8 would end up being 17 px wide rather than 16. This applies for all heights as well as all widths. This basically results in every collision mask, box, or sensor arrangement always being an odd number in overall size. This means they also won't perfectly match up with the evenly sized pixel art.

It's a matter of 1 pixel in width and height, but it could make all the difference in accuracy. To avoid confusion, both measurements will be mentioned (otherwise, refer to image examples).

Hitboxes

Hitboxes represent an area where the Player can detect other objects. All objects can have a hitbox, but not all objects do. Hitbox sizes are not the same thing as the object's Width Radius and Height Radius, though they do follow the same format. They are defined separately and can differ greatly from the normal object size. For example, a ring's Width/Height Radius would be 8, but for it's hitbox it is 6.

The same odd numbered size situation described above also applies to hitbox sizes.

Colliding

The main thing to keep in mind with any object/tile collision is that it typically only concerns itself with any object's whole pixel position, totally ignoring any subpixel amount. So when you perform any collision calculations, you can emulate this by just comparing/testing/using a floored position instead of the real position.

Positions

Game engines these days can effortlessly use real decimal values to move objects around and perform precise calculations. In the original Genesis games, they work a bit differently.

Pixel and Subpixel

Positions and Speeds in the Genesis games are in 2 parts, these being the pixel and the subpixel. The pixel is quite plainly what you would expect, it's what you would see on screen. Think of each pixel as a cell in a grid and this is which cell to look at. The subpixel, however, acts as the fractional part of the position.

Because decimal numbers aren't used, this subpixel actually a positive number up to 256.

Each pixel is effectively split into 256 slices along both axis and this means the finest fidelity available for movement is 1/256th of a pixel (aka 0.00390625). Think of this as where in that grid cell the real position currently is.

All decimal values touted in this guide can be translated into a subpixel amount simply by multiplying them by 256. The Player's acceleration (acceleration_speed) for example, is equal to 12 sub pixels. Their gravity (gravity_force) is 56 subpixels.

If, for example, The Player's X pixel position is 50, and their X subpixel position is 48, the real/decimal X position is 50 + (subpixel / 256) which results in a final X Position of 50.1875. Even when the pixel portion is negative, the subpixel is always relative to the left within that pixel, and is added to the pixel position. So you can easily think of the pixel value to be the object's position, but floored (rounded down). This applies to all positions for any object.

Lastly, this exact same principle is applied to speeds, like an X speed or an acceleration, where they all have a pixel and/or subpixel component. If the value, like acceleration or gravity for example, is less than 1 pixel per frame then it does not need to have a pixel component, of course, and is just the subpixel amount as a single variable.

Using Decimals

Decimal values can be used just fine to emulate this in a modern game engine, but keeping this pixel/subpixel mechanic in mind is important for absolute accuracy.

Angles

Throughout this guide degree angles are counter-clockwise with 0 facing right (flat floor).

Dark blue represents ground, light blue represents air.

This is exactly how programs such as Game Maker Studio work. However, this isn't how the original games work.

Hex Angles

The Mega Drive games use angles in hex, 0 ($00) through 255 ($FF), meaning that there are only 256 divisions of a circle, not 360 like we're used to.

Note: In this case, 256 would be the same angle as 0, much like an angle of 360 is the same as 0.

Throughout the guides, angles will be presented in the following format: Approximate Degrees°, (256 Decimal), ($ 256 Hex)

Not only this, the original game's angles are clockwise while the degrees shown are counter-clockwise (in order to be compatible with common game engines), so be aware of this when reading any angle other the Degrees.

Using Degrees

Degrees are fine to use, however if you want pinpoint accuracy to the originals, you would need to create and use your own angle system using 256 clockwise angles - though for 100% accuracy you'll have to also use the trigonometry functions from the original games

Simply be aware that the degree values presented here are approximate only.

Converting Hex Angles

Of course, if for some reason you only have access to the Hex angle, the 256 slices will not help you if you desire using degrees. And the direction of angles in these classic games is clockwise, unlike other languages such as GML, so $20 isn't 45° like it should be - it's 315°. In order to convert the original clockwise hex angles into counter clockwise degree angles you can use in GML, use this calculation:

 degree_angle = (256-hex_angle)*1.40625

This reverses the hex angle, then multiplies it to fit within the 360 range.