Why aren't there any 1:1 frameworks/engines?

My question is whether there is a "market" for this sort of thing, when ROM hacking resources and tools have matured so much over the decades? I know they're not perfect, but there is a point where a ROM hack might make more sense, if accuracy is passionately desired.

Everyone I've talked to in the fan game scene, at least, doesn't want to work with a 1:1 replication of the classics. It's a more productive use of time to produce a mostly frame-perfect framework, rather than reconciling how to emulate the classics' exact architecture/behavior with modern game making tools. It is an exhaustive exercise of running into windmills, rather than having a game to show for all that effort.

Modern game "engines" can't (easily) simulate the way retro games used to work. For instance, palette-swapping needs to be done with shaders nowadays, (which crashes on some iGPUs) sine-wave ripple effects are very costly on the GPU, and extra math is necessary to force a game to work with 255 degrees, instead of radians. (The former of which the classic Sonic games do.) We also have to proactively file off "sub-pixel" movement for every object, which might feel cumbersome while coding complex games like Sonic.

Tile "engines" have also changed a lot, and for the better, really. The classics work with "chunks", rather than with individual tiles like Sonic Mania does. The latter is more tedious, but it gives the developer more control and the potential for clever level design work, while the former is very restrictive.

What we would get at the other end of this creative exercise, I think, is a framework that asks more CPU/GPU time on the average computer, (the desirable "target" hardware for a fan game) than a framework that embraces modern, performant programming choices, and QoL mechanics that make Sonic's movement smoother and more fun to play.

Unless somebody wants to program it all in C++, like Steath and Taxman did, a 1:1 framework could have more performance overhead in GameMaker / Unity / Godot. That overhead starts to add up once complex stage design is in the picture.

 

A chunk is nothing more than a template of tiles, so in my view, it makes less sense for a game that doesn't have the same memory constraints as the originals to be limited to a collection of templates. Templates can be handled by a level editor and let the game simply focus on handling the actual tiles.

But to the point that 1:1 doesn't exist, some of this stuff is close enough for 99% of everyone out there. It is a questionable investment since few would ever notice (or care) about the difference.

I spent a little over five years trying to create 1:1 via ProSonic. The hard lesson I learned is that while it's definitely possible, it becomes a major distraction with little to show for. At the end of the day, most people just want a game to play.

 

Also, a lot of the ways the old Sonic games worked weren't really very accurate, they were simply performant given the hardware. Things like fixed width decimals or fixed step physics calculations. Fine for a 68000 running at 7 mhz, skimps on heavy calculations when it can, but today's modern processors can do much more complex calculations much quicker. You don't need to rely on a table of only 255 sin values accurate only to the thousandths place anymore when you can just as easily do full on floating point arithmetic. With access to actual vector math, you can produce much better checking, more accurate physics than what a genesis could produce. Point is, the old games are full of bugs introduced by the inaccuracies caused by the simplification of the underlaying math.

 

I think the biggest flaw with the original engine's physics comes down to the collision detection and not the movement. Collision with the stage is basically done with 2 points at Sonic's feet (or head if checking ceiling collision), 1 on each side. There is also another point that is placed right in front of Sonic to handle walls. The angle of each block is also manually hardcoded, even for sides that don't have that angle (this is basically why there's a special tag you can assign on walls, floors, and ceilings so that Sonic can properly snap to them when moving along them). It also does not account for if Sonic is moving too fast to the point where he skips over blocks, because it only checks collision at the points once (see this. At the very most, it will check a block above or below Sonic to calculate how deep Sonic is into a block or how far above he is from the floor, but that's it).

Now, in most cases, this works fine, but there are a bunch of edge cases, some more severe than others (a couple are pointed out here and more here) involving collision that happens inbetween these points, but not at the points. Of course, the games were designed to avoid these issues as much as they could in the stage design, but you can still trigger them with some well timed positioning and stuff. Can't exactly fault Yuji Naka though, considering the hardware limitations, but these days with modern engines, you can quickly and easily detect collision with actual hitboxes and vector polygons and even be able to automatically calculate the angle based on the "normal" vector of the surface collided with.

You can still program it in a way that accurately recreates the movement physics while also having a more solid and less buggy collision detection system. However, if you so desire, you should still be able to recreate the original collision detection method with basic point collision or raycasts, and perhaps even set up a custom property for each block for hardcoding the angle values. You should also be able to set the collision shape to match the shape of the pixels in the original collision blocks, as opposed to approximating it with a vector polygon and accounting for that appropriately, if you really want that additional layer of accuracy.

 

My answer would be that many frameworks are created for game-making software like Game Maker and Clickteam Fusion. I've never used them, but I know that they have a framework of their own, which I imagine isn't always a good fit for every Sonic game feature. Then there's the fact that when it comes to programming, they use scripting languages, which give you less flexibility, making it harder to replicate the original logic.

It's also worth mentioning that, having tried to program a game from scratch for years and not finding any resources on how to do so past the basics (blitting an image on the screen, reading input, basic animation,...), game programming without using a pre-made framework is a lost art.

 

If you want a recommendation of a framework that is faithful enough, then Orbinaut Framework for Game Maker Studio 2 works pretty well from what I've tested. I believe it actually implements the original method of collision detection, too. GMS2 also backpedaled from their subscription model (outside of console exports, which I would believe is enforced upon by the big three).

 

The original game engine was incredibly buggy, full of "Robotnik's diabolical traps" and a fair few things that doesn't make sense physics-wise (for example, the only reason you can gain height in a half-pipe is because the game takes shortcuts in how air speed is converted to ground speed). A lot of it is necessary for good performance on 35-year-old hardware, but not necessary today. Why copy all the buggy behaviour when it's easier in modern engines to have something almost identical but without the buggy behaviour?

 

I think "incredibly buggy" is an unfair assessment. The engine worked well for what it set out to do, and things like "Robotnik's diabolical traps" are edge cases/flaws of its design. Other things could be called features, not bugs.

 

Depends what aspects you want to have 1:1!

If you mean the way things collide, move, and animate, then they do exist. The Sonic Physics Guide exists for a reason The engine being used, such as Game Maker or others, aren't really a limiting factor if you are doing everything from scratch.
Example: Orbinaut Framework for Game Maker is written to mimic the original physics and code as best it possibly can, using custom coded collisions and a Solid Tile system which also mimics the original (there are others that have the same goal, I just happen to know the most about that one).

Also depends how strict your definition is of course... for the purposes of this post I am talking accuracy that is perfect under typical scrutiny. Not necessarily uber-subpixel-replay perfect.

 

I wanna mention another thing, if you are just interested in the movement physics and not the collision detection, then I have been working on a Godot recreation of Sonic's physics from the Genesis games as closely as I can while still using the built in collision functions, for a potential video series. Maybe once I get that stuff up and running, it could act as a potential resource? I did see another project that also did that, but they also recreated the original collision detection with raycasting and stuff.

 

Really? I would have imagined that this was a deliberate design choice, since otherwise, you'd probably be stuck at the bottom of that one massive half-pipe in Spring Yard Zone - Act 3. Unless you mean jumping afterwards, in which... sure.

 

I give my point of view, as I already said here, for months I have been building an engine (from scratch, my idea is to make an engine to create a complete Sonic game, not just levels) and, delving into the technical details , I agree with several comments here.
It is preferable to make an engine as close as possible to the original, but technically modern, without the limitations of the Mega Drive.

That's the path I finally chose, to have the best of both worlds.

 

You can get out of that half-pipe without rolling, and there are platforms to help with that. Probably the biggest clue that it's not deliberate is that the height you get fluctuates depending on where your position lines up when you fall.

 

...I never realized that's what those platforms and bumpers were for.

 

I would still argue that it's a deliberate choice, because of the field of rings in the air in Green Hill Zone act 1. If that physics decision wasn't deliberate, then originally there would have been no way to reach those rings, as we know the platforms near the top were added late in development. That entire ring field is predicated on you gaining more height than your initial starting height while rolling.

 

You go from the start of the S tunnel to the rings without landing on the ground again, so this "decision" doesn't even come into play here.

 

I do think in most cases people seek to have a framework or engine that not only is just generally easy to work with and also easy to alter in case they would like to change physics values around to better match what they want to achieve for their project. It also allows the end user to take more advantage of the features the software it's made in brings to the table. We're living in a time frame where we can be at a ludicrously close approximation of the 16-bit titles, but to go the whole 9 yards and go for something that's 1:1 comes at a cost of flexibility or the ability to improve upon the flaws of the original titles.

Orbinaut in particular comes to my mind as it's accurate to a fault in the sense that they also brought over a lot of the collision data, requiring you to use a separate editor to even be able to utilise them and even then you're still a bit limited in what you can achieve with that compared to having collision prediction set in your framework and create collision masks or tiles of any kind so in that regard you cannot really be all that versatile with that framework in particular.

 

It's more complex than that.

When launching up into the air, Sonic won't be registered as in the air until he has totally gone off the terrain, since Sonic will roll up the ramp and onto the wall. However, when in the air, Sonic cannot land on the same wall he launched off of. Instead, he will land on the sloped part of the ramp. This basically means that Sonic has more airtime moving down than moving up in this case.

In the case where you're not launching out of the ramp, and just building speed within it (like in some sections of Spring Yard Zone with the tall walls and ramps on the bottom), then it's also a matter of gravity being stronger than the upwards slope resistance. When running, the upwards slope resistance is 0x20 (0.125), and when rolling, it's 0x14 (0.078125). Gravity is fixed at 0x38 (0.21875) when above water. When moving upwards, Sonic will be considered on the ground, moving up the wall, and it will thus use the appropriate upwards slope resistance to slow him down. Once Sonic loses enough speed, then Sonic will fall off the wall and then be registered as in the air, in which Sonic will propel downwards via gravity, which again, is stronger.

There's also the fact that when rolling, the downwards slope resistance is 4 times greater than the upwards slope resistance, and that was done deliberately. By default, it uses 0x50, but it takes into account the angle and velocity Sonic is at to check if he's moving up or down a slope, and if he's moving upwards, 0x50 is divided by 4 into 0x14. I think this particular imbalance is a piece of evidence that it was intended for Sonic to gain speed in these ramps, at least while rolling... and just wanna add that this maneuver is featured in the end credits of Sonic 1, so...

The speed does get capped at 0xFC0 upon landing, which I believe was done to mitigate collision issues due to potentially skipping over blocks, but that's all that's for.

 

While all of that's true (and I didn't actually know about the speed cap on landing), the issue I'm referring to is the way ground speed is calculated on landing; it will only ever be based on your X speed or your Y speed, never both; and often this can lead to very unintuitive behaviour (like shooting up a slope when you land on it almost perpendicularly, if your X speed happens to be higher than your Y speed).

But yeah, I'm wrong that it's the reason you gain height in a half-pipe. It's the "gravity only applies while you're in the air" thing.