Hi, I've been lurking around here for 10 months or so and have found the physics guide and various posts in the forum extremely useful and helpful with lots of information that is useful to understanding how Sonic 1 worked. Probably like a lot of people, I was blown away with Sonic 1 when it first came out, although I never had a megadrive it impressed me a lot as a young programmer and I always wondered just how they achieved the end result. I suffer with insomnia and I've been meaning to write a game for a long time, the last game I wrote was back in 1992 and I've spent several years telling myself to write a old school platform but it's never got past thinking about it. I decided that as a refresher and also to understand how the original game worked (to cure another itch!) I decided that I'd have a go at re-creating bits of sonic 1, since there was plenty of information out there and with the disassembles, the possibly of using real data that was used in a real game seemed like a useful exercise. What I didn't count on was how much effort it would be to extract that data into easily usable data, by that I mean I could have just used the data as is, but I decided to extract it into JSON and PNG files since I could look at the data and easily modify it, I have a tool that's held together with sticky tape that alongside the disassembly it extracts the data with meaningful names and so on, it's easy to look at, since I was going to only implement small parts the ability to change stuff easily was a motivator to creating my own platform engine. Now.... As I got deeper into the mechanics of the game, I reached a point where I'd implemented so much that it seemed silly not to complete the engine so that it could play the GHZ levels in full, so I ended up going much further in what I implemented than I actually intended to implement. I'm now at a point where I'm going back and fixing the many small issues that existed, the engine was written over about 2 months in my free time on and off but for the past 6 months I hadn't touched it due to lack of time, now I'm back fixing stuff. One thing I can't seem to get a handle on is the S-tunnels, Sonic just doesn't go through them with the speed of the original engine, I've spent a lot of time going through the disassembly but I can't see what I'm doing wrong. If I remove the cap of x speed of 16 then he does indeed speed up - way too much. The chunk between the s tunnels seems to be causing the issue, once he exits the first tunnel his ground speed is capped making him lose momentum, I think this is the issue but I've probably spend too much time staring at the code now and I may be missing something entirely obvious, I'd be interested if anybody has any deeper knowledge! The first video is one I just recorded of me speeding through to the s tunnels, the second video is from a much earlier version of the engine but with the various debug options turned on and off to see what the engine is doing.
Ok, I don't think I read the page correctly, it seems his ground speed should not be capped as page also makes note of this because it can cause a sync loss. Going to have to delve in deeper.
So your goal is to create a Sonic engine that accurately recreates classic Sonic physics? Sorry I don't have anything to add to finding the solution to your problem but I do have a question. As you know, in classic Sonic games all the walkable surfaces have a register that tells the collider(s) what is the floor angle it's on. In all modern classic engine recreations however, the character typically has two colliders (one to the left, one to the right) and the game calculates the floor angle using a cosine function. I believe that's how it's done in Mania too. How is it done in your engine? Because this is the fundamental difference that doesn't let all the modern classic Sonic engines to be 100% true to the original.
Thanks for the reply, the answer to that is yes and no! I started the engine purely as a means to refresh my memory with the kind of techniques used in platformers, since sonics terrain was much more complicated than other platformers of the time, it seemed like a reasonable place to start, especially given that there were disassembles as well as the excellent physics guide here. I never intended to go anywhere near as far into recreating sonic, but I got to the point where I'd implemented so much of it, that I may as well just finish the engine to a state that the GHZ levels run. I implemented it according to the physics guide here and by looking at the disassembly when I had trouble visualising or where stuff simply isn't covered in the physics guide. So as far as I know, it's faithful to the original game, unless the physics guide isn't? Yes, sonic in my engine has 2 downward sensors (well, 3 but the third one is only used for the balancing animation when he's stationary and only one of his ground sensors are active). The floor angle is calculated according to the solid that is causing the ground collision and is used to accelerate or decelerate sonic and to make him slide down steep surfaces, and to provide the correct direction when sonic jumps on a surface that isn't level. As he moves through the s-tunnel the solids move him in and out of the ground and left and right wall mode, the problem was me capping ground speed, the psysics guide states that it isn't capped when he's rolling, rather the X speed is capped but Y has no cap, while it's not quite right at the moment for me, he's moving too fast, it is much closer now, I need to delve deeper into this.
Hello, I've added a lot to the Physics Guide over recent years. I must say, what happens in the tunnels in those videos is quite strange! There's an apparent instant speed boost when you enter rather than gradually gaining that speed as you descend. Also, the slowdown I see in the middle, I do wonder why that is. Seems very slow. I'm curious if you're limiting Ground Speed to 6 when rolling? (I can tell it's not the 16 cap because that's still extremely fast) Only time the 6 Ground Speed cap comes into play on the ground is when running and holding forward. It does not apply when rolling even when holding forward. During and between those tunnels Sonic's rolling Ground Speed should be able to surpass 6 easily, without being limited. As the guide describes, there's only the X cap of 16 when rolling. The overall rolling physics in the tube matches how Sonic works everywhere else apart from the very specific things like not being able to unroll and the slight nudge it gives if you stop. There's essentially no trickery at all.
thank you I very much appreciate your input to the guide, it’s a fantastic resource. I have some stuff I can contribute back, specifically around the moving platforms that don’t appear to be detailed. I will get back to you on that, I’ve modified stuff over the weekend and I can’t remember what changes I’ve made now, I will digest the stuff here and let you know. Now I have moved the ground speed cap and have left the x cap in, but now he appears to go too fast through the tunnel section (compared to an emulator) although the point he hits the coins is around about the correct place. [/QUOTE] ok that’s good to know, is he something pretty silly, I will just have to grind my way through this now, at least in the knowledge that there’s nothing particularly special that needs doing.
I think I've resolved it, there were a couple of issues, as some point I put some code in as a test and never removed it and that was causing a domino effect. I very much appreciate your response here as well as your contributions to the physics guide. I don't really know what the "remit" of the physics guide is, while a lot of it does cover the game physics there's also stuff what covers more general stuff relating to the game engine rather than pure physics. One thing that took me a while to figure out was the platforms and how the oscillations were managed, I would be happy to detail this if it's of interest to the physics guide, since nearly everything you need to re-create or understand the engine is documented.
More "technical" details will be added soon, such as various angle calculations made in the original games that can be used instead of the typical sine functions for example. Ideally, the way the original game calculates things like that will be documented there as it's a key step in making things accurate. There's already an element of it with the original game's 256 angle values given along with the degree conversion, and the subject of subpixels being brought up briefly, but there's no explanation yet on how to use those directly. The guide currently explains the basic intention of behaviour just fine but does skim over (or ignore) some of the details behind the scenes that ensure 100% accuracy.
