Fixed! And reworded a little. Was left over from way back when the guide always referred to Sonic's speed on the ground as X Speed instead of Ground Speed outside of the original Solid Tiles page (as that was the only page that described that whole system & explained slopes originally)
Recent additions/changes made: Solid Terrain page added (pretty much what foobles was asking for a few posts back) Acts as a part 2 to Solid Tiles page Where part 1 describes what solid tiles are, part 2 describes how they are used to create complex terrain. Describes collision layer switchers, and touches on sprite priority Shows examples of their use, such as Loops and the weaving Waves in Chemical Plant Will add more explanations related to how certain set-pieces or structures are built from Solid Tiles in future.
Some notes about SolidObject: Horizontal collision is considered active when Sonic is inside the object, and also when the distance between the object centers is EQUAL to the minimum distance (when he's just resting up against the object, and not necessarily in it). Sonic CD did make a change to the above by making it so that Sonic must be inside of the object to activate collision... at least when Sonic is right of the object. It's still the same logic as before if he's left of it instead. This in particular has an effect on a monitor's solid collision, where it can be considered 1 pixel larger than the destruction hitbox. Sonic can rest up against the left side of the monitor, even in a ball, and not destroy it. This is not the case when rolling into the right side, where Sonic must be partially inside for the collision to activate, and by then, the destruction hitbox will also be collided with. Vertical collision is uses the same logic as with Sonic CD's horizontal collision check, even in Sonic 1, just replace "left" with "above", and "right" with "below". In either case, in an event where the the distance is equal to the minimum distance needed, and collision is activated, you don't really see it anyways, because it shifts Sonic out of the object by... 0 pixels!
Pardon another nitpick, but I have some questions/possible correction to the section about springs in the Game Objects chapter. It says that horizontal springs only activate when Sonic is grounded, but through my testing in the S3&K debug mode, springs do activate while he is airborne. Maybe they only activate while grounded in Sonic 1? I couldn't verify whether or not it happens in S1 because for some reason, the debug mode would not let me place horizontally facing springs. Also, the section on springs says that they affect Sonic's X Speed and Y Speed variables. But this doesn't seem to be the full story because, while grounded, Sonic's X and Y speed variables are overwritten based on his current Ground Speed. Does it also set ground speed so that it works while he is grounded? I tried hitting a horizontal spring while running upside down on a ceiling, and it pushes back in the correct direction. Therefore, if it does affect ground speed, it must take into account which of the 4 direction-modes Sonic is currently in. I can do some more research if necessary and try to find an explanation for this, but I thought it was worth mentioning.
Thanks for pointing these out! https://mobile.xcancel.com/SonicPhysics/status/1347190381323182080 It's a thing in Sonic 2 also, but you are correct, Sonic 3 fixes this. Also, that second part regarding X Speed is another leftover from early versions of the guide where the concept of Ground Speed wasn't explained/used outside of the early Solid Tiles page. These have been corrected!
The SPG Sonic 2 Collision Overlay Script is here! https://info.sonicretro.org/SPG:Overlay_Scripts Just like the first, it shows sensors, terrain tiles, layers, hitboxes, solidity, sizes, variables and more in real-time as you play. Credit to Mercury for the solid tile display and assistance. Give it a try, using Gens Re-Recording!
00:07 Something's fishy. I could swear I would get hit every single time I try to jump on shellcracker at that angle
Yep haha! That's one of the bigger revelations. The claw has to be fully retracted for you to pull that hit off as there is no claw "hurt hitbox" in that state, otherwise you have no choice but to try jump over the large arm hurt hitboxes and hit the right side of the body.
Recent additions/changes made: Information on water has been expanded: Underwater page now includes information about remaining air and drowning. Game Objects page now includes the mechanics of the Air Bubble Makers, and the water bubbles themselves. (Credit to Mercury for the research.) Information about underwater speeds has been reformatted.
Recent additions/changes made: New Calculations page added https://info.sonicretro.org/SPG:Calculations This page details the specific ways the original games store and process values such as speeds, positions and angles. Only really necessary for going the extra step for accuracy (using decimals and degrees works fine otherwise) Some of this information was originally on the basics page and has found a more relevant home on this new page. More information to be added. Added demo gif for the Maze Special Stage rotation illusion https://info.sonicretro.org/SPG:Special_Stages#Rotating_Maze
Recent additions/changes made: New Player 2 page added https://info.sonicretro.org/SPG:Player_2 This page details the CPU control and respawning for Player 2's AI. Moved character abilities back to the main abilities page, away from the characters page. Characters page can focus on how characters differ in how they are set up. Separated elemental shields and their powers onto their own page for easier/intuitive navigation. https://info.sonicretro.org/SPG:Elemental_Shields
Lapper, your work on the SPG has been amazing and inspiring. Between what you with Mercury have done with the overlays to the easy to read, digestible sections in the guide itself: I'm beyond impressed. As a developer, I've long wanted to write my own Sonic physics engine; Either for an existing game engine, or to build it into an engine from scratch. Over the years though I never got the push to do it because I never really could see the value of adding "just another physics framework" to the already vibrant Sonic fangame community. However, sometime last year after seeing everything you've been doing with this guide I started chewing on that again and I think I finally have settled on the angle I want to take now. I'd like to build this engine (or engine component) as a companion / reference to the work you've done in the guide. I want to build it in a way that the guide can reference bits of it's implementation to explain or fully define topics, as well as the code itself can reference back to the SPG as to why it makes the decisions it does, reasons for what may seem like "buggy", behavior, etc. The idea that I have is to build out something that's realized enough for someone new to the scene to come along and both find inspiration in it, as well as being able to trust that it's as close to a "canonical" implementation as possible. I intend for it to be as "readable" and "logical portable" (so probably in a C-style language.) I also plan to keep as permissively licensed (likely 0BSD, as that's I try to use for the majority of my work,) with the goal is that they'd be able to use it wholesale or piecemeal in their own game/engine. If you're interested in collaborating, I'd love to do so; If not and you're much too busy (like we all are ) then no worries at all — but do know that your feedback would always be welcome.
Recent additions/changes made: New example images Image examples related to angles and collision modes have been added or updated to be clearer. Here is just a small selection of them. The Landing On The Ground section on the Slope Physics page had very old information, and has finally been greatly updated. This section was probably the "oldest" in terms of it's information, which was often reformatted and made more accessible, but not double checked or updated. It's finally had that attention. Corrected/accurate angle ranges. These were only off by a "degree" in any given error, but the accurate values are now present. Correct requirements/reaction for landing on ceilings. Most notable info update is that you can't land on a ceiling unless you are moving "mostly up" in the air. Information about 360 Collision (mode switching) information has been moved from the Slope Physics page to the Slope Collision page (where it obviously belongs) ---- Also, CMD, Interesting idea. I have been thinking about some sort of "reference" page on the guide which references to sections of the guide and walks through small portions of the original code. A reference engine is another cool thought. I feel like it'd be a good authority if it was a direct translation of the original game code into something newer, with references to the guide at every turn, rather than an example that is itself made using the guide. The guide is constantly being updated with new info and corrections (like shown above). It's approaching some level of "perfection" but I don't think it's there yet. That doesn't mean I don't think a pure implementation/translation the guide would be very handy for people, as long as it is clear that's what it is - though it'd have to be updated alongside it.
That would be interesting, though I imagine a pure translation would need to be built up from scratch in SDL or something since the tile system used by the original games simply isn't used anymore in any modern game engine. And speaking of modern game engines, that brings up the matter of applicability, I suppose, whether it'd be worth more to develop something still engine-agnostic but still more applicable to other game engines or a fully-faithful implementation. Both would have their merits, though, I suppose. I'm actually surprised how spotty implementations are in modern engines. Sonic Worlds Next in Godot is still in development (specifically currently on Godot 4) but there's no 3D Godot implementation, there's no up to date Unity implementation in either 2D or 3D (Sonic Realms technically works when converted to modern Unity versions but is fairly barebones, and Hedge Physics technically works but its use of Blender-based assets makes converting it to more modern Unity versions a complete mess) and there's no 2D implementation in Unreal (albeit understandable, even if plugins like PaperZD make 2D work in Unreal much more viable), and the 3D frameworks are kinda more geared towards more modern-style gameplay. I can't speak for Game Maker or Construct 3, though, I never used Game Maker and I haven't been in the Construct dev scene for years, even if I do still have some fondness for how Construct does things, though I kinda understand why people don't use it as much nowadays.
Recent additions/changes made: Sonic Mania jump height difference explained on the Jumping page. New collision/trigger example images for objects such as capsules, fans, and spikes. Some examples: Character hitboxes are now shown on the Characters page in addition to their actual sizes (to avoid confusion). Some examples:
Recent additions/changes made: Push Sensor mode change angle range differences are now explained. Push Sensors rotate sooner than Ground Sensors when climbing a quarter pipe. New updated & accurate gifs which reflect the reality of how the mode changing works/looks (namely, the push sensors rotating at a slightly different time/angle) Added image for large air bubble trigger
Could the rotating maze section of the physics guide be expanded and more thoroughly explained? alot of the details on how horizontal movement works in tangent with the rest of the gravity physics are lacking, and certain visuals are misleading, making recreation confusing. thanks!
Minor question but how do the scattered rings in Mania behave? The current Game Objects page is focused on the MD + CD games, which don't care about walls. Mania's scattered rings do care about the walls but I can't make heads or tails (or Miles) since I don't have experience with C.
I haven't looked deeply into it, but from a quick skim I believe they just reverse their X Speeds when hitting a wall and also reverse Y Speed when hitting a ceiling.
Hello, I have a question regarding the angles of the collision tiles. I am developing the engine (Seek Engine) and I have already finished the collision editor (photo attached), each collision tile can be assigned an angle (the rest of the properties, such as the type of collision or if it is flipped / marked are defined elsewhere). The only question I have for now is the conversion of the angle in the different player modes. My current algorithm is the following: (Pseudocode) If the player is in floor mode, the same angle is returned, without modifying it. If the player is in right wall mode: 90° - Angle If the player is in ceiling mode: 180° - Angle If the player is in left wall mode: 360° - Angle Is this algorithm correct?
