Actions

Difference between revisions of "SPG:Basics"

From Sonic Retro

m (General fixes)
(Hitboxes: Grammar error)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
''Notes: Research applies to all four of the [[Mega Drive]] games, and [[Sonic CD]]. If there are any varying differences between the games, this will be covered below.''
+
{{SPGPages}}
 +
'''Notes:'''
 +
*''Research applies to all four of the [[Mega Drive]] games, and [[Sonic CD]].''
  
 
==Introduction==
 
==Introduction==
Line 6: Line 8:
 
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.
 
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.
  
==Positions==
+
==Objects==
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.
+
Objects are the moving building blocks of each Sonic game (aside from the Terrain Tiles or [[SPG:Solid_Tiles|Solid Tiles]] which physically make up the Zones and Acts themselves). [[SPG:Characters|Characters]] are objects, [[SPG:Game_Enemies#Badniks|Badniks]] are objects, [[SPG:Game_Enemies#Bosses|Bosses]] are constructed from multiple objects, [[SPG:Game_Objects|Game Objects]] such as [[SPG:Game_Objects#Springs|Springs]] or [[SPG:Game_Objects#Item_Monitors|Item Monitors]] are objects, and so on.  
  
===Pixel and Subpixel===
+
===Variables===
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.
+
The following object variables/constants will be referenced frequently in this guide.
  
Because decimal numbers aren't used, this subpixel actually a positive number up to 256.  
+
{| class="prettytable" style="width: auto;"
 +
!Variable
 +
!Description
 +
|-
 +
|'''''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, or 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.
 +
|}
  
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.
+
Note: ''These apply to the Player and other objects. Though, of course, some objects have no need for Ground Speed or even other variables if they do not move or do not collide with the terrain.''
  
All decimal values touted in this guide can be translated into a subpixel amount simply by multiplying them by 256. Sonic's acceleration (''acc'') for example, is equal to 12 sub pixels. His gravity (''grv'') is 56 subpixels.  
+
====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.
  
If, for example, Sonic's X pixel position is 50, and his X subpixel position is 48, the real/decimal X position is 50 + (subpixel / 256) which results in a final ''xpos'' 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.
+
[[Image:SPGHitBoxRadius.png]]
  
Lastly, this exact same principle is applied to speeds, like an X speed or an acceleration, where they all have a pixel and subpixel component.
+
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.
  
===Using Decimals===
+
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).
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==
+
=====Hitboxes=====
 +
[[SPG:Hitboxes|Hitboxes]] represent an area where the Player can detect other objects. Most 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''.
  
Degree angles are counter-clockwise with 0 facing right (flat floor).
+
The same odd numbered size situation described above also applies to hitbox sizes.
  
[[Image:SPGAngles2.png|link=Special:FilePath/SPGAngles2.png]]
+
===Colliding===
Dark blue represents ground, light blue represents air.
+
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.
  
===Hex Angles===
+
==Positions And Speeds==
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.  
+
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.  
  
Note: ''In this case, 256 would be the same angle as 0, much like an angle of 360 is the same as 0.''
+
===Pixels and Subpixels===
 +
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, the integer or whole-number portion (or the value, floored), 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.
  
Throughout the guides, angles will be presented in 3 forms. Converted degrees, Inverted Decimal (the real hex values, converted to decimal, and reversed to be anti clockwise for comparison with the degrees), and the original hex value. Degrees are fine to use and are far more intuitive, however if you want pinpoint accuracy to the originals, you would need to create and use your own angle system using 256 clockwise angles.
+
Because true decimal numbers aren't used, this subpixel actually a positive number up to ''256''. This effectively splits the pixel into ''256'' slices of precision.
  
====Reference: Converting Hex Angles====
+
[[Image:SPGSubpixels.png|link=Special:FilePath/SPGSubpixels.png]]''A single pixel in the classic Sonic games. Each square here is a subpixel''
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. Worse, the direction is anti-clockwise compared to other languages like GML, so $20 isn't 45° like it should be - it's 315°.
 
In order to convert the original hex angles into angles you can use in GML, use this calculation:
 
  
  real_angle = (256-hex_angle)*1.40625
+
It's fine to use decimal values and keep extremely close accuracy in a modern game engine, however for more info on how they actually work in the original game, see [[SPG:Calculations#Pixel_and_Subpixel|Pixel and Subpixel]].
  
This reverses the hex angle, then multiplies it to fit within the 360 range.
+
==Angles==
 +
Throughout this guide degree angles are counter-clockwise with ''0°'' facing right.
  
==Objects==
+
In the context of the Players '''''Ground Angle''''', this looks like the following:
Objects are the building blocks of each Sonic game (ignoring the Terrain Tiles). Sonic is an object, items are objects, and so on.
 
  
===Variables===
+
[[Image:SPGAngles2.png|link=Special:FilePath/SPGAngles2.png]]
  
The following variables/constants will be referenced frequently in this guide.
+
The arrows represent the angle of the ground. ''0°'' represents a flat floor, ''180°'' represents a ceiling.
  
<nowiki>//General Object Variables/Attributes
+
===Hex Angles===
X Position: The X-coordinate of the object's centre.
+
Like positions and speeds, angles are also formatted differently in the original game. These will be called Hex angles.
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.
 
 
 
//Sonic's Variables
 
Push Radius: Sonic's width from the origin pixel left and right (for pushing).
 
Slope Factor: The current slope factor value being used.
 
 
//Sonic's Speed constants
 
acc: 0.046875    ;acceleration
 
dec: 0.5    ;deceleration
 
frc: 0.046875    ;friction (same as acc)
 
top: 6    ;top horizontal speed
 
slp: 0.125    ;slope factor when walking/running
 
slprollup: 0.078125    ;slope factor when rolling uphill
 
slprolldown: 0.3125    ;slope factor when rolling downhill
 
fall: 2.5    ;tolerance ground speed for sticking to walls and ceilings
 
 
 
//Sonic's Airborne Speed Constants
 
air: 0.09375    ;air acceleration (2x acc)
 
jmp: 6.5    ;jump force
 
knxjmp: 6    ;knuckles' jump force
 
grv: 0.21875    ;gravity
 
</nowiki>
 
 
 
===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.
 
 
 
For the most part, the width and Height Radius of an object describes it's solid size, so it's the box size if you can push against it 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.
 
  
[[Image:SPGHitBoxRadius.png]]
+
Again, it's fine to use normal 360 degree angle values when following this guide for extremely close accuracy in a modern game engine, however for more info on how they actually work in the original game, see [[SPG:Calculations#Hex_Angles|Hex Angles]].
  
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 pushing Width Radius of 10 become a total width of 21, '''not''' 20. 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.
+
==Formatting==
 
+
* Object variables will be displayed with the following format: '''''Variable Name'''''.
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).
+
* Constants will be displayed with the following format: '''constant_name'''.
 
+
* Various values and numbers will be displayed with the following format: ''123''.
====Hitboxes====
+
* Fractional values representing speeds or positions will be displayed with the following format: ''Decimal (Subpixels)''.
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.
+
* Angles will be displayed with the following format: ''Degree Conversion° (Hex Angle)''.
 
 
====Characters====
 
Characters follow the same format as any other object for the most part. But there are some specific character traits that can help you get started.
 
 
 
Sonic's Width Radius  is usually 9, and his Height Radius is usually 19. These radiuses determine where Sonic's floor and ceiling tile sensors will be. These can change depending on Sonic's action, and how they behave will be described in Solid Tiles, as they are most relevant to collision specifically.
 
Sonic also has another radius that he uses for pushing against objects and tiles. We will call this his '''Push Radius''' which is always 10. This radius is implied via being used for the sensor positions and during object collision rather than actually defined as a variable in-game, though it simply makes more sense here to describe it as a constant.
 
 
 
===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.
 
  
 
[[Category:Sonic Physics Guide|Basics]]
 
[[Category:Sonic Physics Guide|Basics]]

Latest revision as of 08:02, 9 March 2024

Sonic Physics Guide
Collision
Physics
Gameplay
Presentation
Special

Notes:

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.

Variable Description
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, or 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.

Note: These apply to the Player and other objects. Though, of course, some objects have no need for Ground Speed or even other variables if they do not move or do not collide with the terrain.

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.

SPGHitBoxRadius.png

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. Most 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 And Speeds

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.

Pixels and Subpixels

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, the integer or whole-number portion (or the value, floored), 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 true decimal numbers aren't used, this subpixel actually a positive number up to 256. This effectively splits the pixel into 256 slices of precision.

SPGSubpixels.pngA single pixel in the classic Sonic games. Each square here is a subpixel

It's fine to use decimal values and keep extremely close accuracy in a modern game engine, however for more info on how they actually work in the original game, see Pixel and Subpixel.

Angles

Throughout this guide degree angles are counter-clockwise with facing right.

In the context of the Players Ground Angle, this looks like the following:

SPGAngles2.png

The arrows represent the angle of the ground. represents a flat floor, 180° represents a ceiling.

Hex Angles

Like positions and speeds, angles are also formatted differently in the original game. These will be called Hex angles.

Again, it's fine to use normal 360 degree angle values when following this guide for extremely close accuracy in a modern game engine, however for more info on how they actually work in the original game, see Hex Angles.

Formatting

  • Object variables will be displayed with the following format: Variable Name.
  • Constants will be displayed with the following format: constant_name.
  • Various values and numbers will be displayed with the following format: 123.
  • Fractional values representing speeds or positions will be displayed with the following format: Decimal (Subpixels).
  • Angles will be displayed with the following format: Degree Conversion° (Hex Angle).