Some changes/fixes for Sonic 1

Yeah the roll jump lock was definitely set in place due to the air speed cap. But since we have guides to remove the cap, we can also remove the lock.

 

2010 is not ancient and we were very much aware of the air speed cap back then.

EDIT: In fact it's even brought up in the thread.

Just to add more to this: removing the air speed cap is a much easier fix than implementing a roll jump lock. For this to be the case, you're telling me the guy who wrote the physics engine for the game (Yuji Naka himself, no less) doesn't know how conditional branches work.

The much more likely scenario is that nobody during Sonic 1's development even noticed the speed cap reduced your speed if you were above the cap, because there are very few scenarios where that can even happen in Sonic 1. Despite my initial leanings towards it being air cap related in that thread, I've actually dived into the code since then and I doubt the roll jump lock has anything to do with the air speed cap.

 

2010 was 14 years ago. It's closer to the creation of this website than it is to today.

I thought rolling down hills and half pipes to pick up speed was basically one of the selling points of the game? Spring Yard Zone act 3 is a prime example, where it begins with a massive downward slope for you to roll down, which makes the air speed cap issue very apparent if you jumped after rolling down it.

Yuji Naka is not above quick and dirty hacks, and his code is literred with other sorts of issues. His engine was clever, for sure, but it wasn't perfect. The lock isn't even remotely complex, and I'd even argue it was a temporary fix that was made permanent, because...

The air speed cap kicks in if you press left or right while in the air, because the functions for handling that check Sonic's speed. The lock simply skips over that. Can't wreck the momentum of the jump if you don't let those functions mess with it. Quick and easy fix that gets the job done.

 

Yes? Sonic 1 is littered with instances of Naka forgetting if he's counting from 1 or 0. Using the wrong registers. Object memory spamming with things like bridges and swings. There's a reason we got a billion fixes for this game. In fact one of them is a bug stemming from the incorrect use of a conditional branch.
I hate this idea that Naka is some genius that was unmatched with the Genesis when he just knew how to use premade trigonometry functions.

 

SYZ3 is... basically the only scenario you'll see this in in Sonic 1. And if you roll down the slope and don't jump at the bottom (which I guarantee most people did the first time they played)... your air speed is still capped as soon as you leave the slope at the bottom!

The one situation you're likely to encounter it and it doesn't fix it. Great fix.

It's not that simple. The roll lock needs to be set when jumping from a rolling state; it needs to be cleared when landing on ground, and when landing on objects (which is handled separately), and when interacting with various different objects. And every object you touch has the potential to add more bugs.

Saying "if speed > cap don't accelerate" is much quicker and easier, especially since if you don't mind Sonic's top speed not being exactly 6, you can simply change where you do the branch. Granted, it has to be done twice (hi Sonic 2).

The roll jump lock does nothing to fix the ground speed cap issue, which can happen in more situations and is even more obvious when it does. You'd think there'd be something to patch that one too... or are you going to claim that the inability to accelerate on flat ground while rolling is a "quick fix" for that one too?

Nobody made this claim.

Yes, there's a ton of bugs. Bugs happen. But when you have a bug in code you've written, and you're made aware of the bug, you usually have a decent idea of how to fix it, especially when it's something this simple. You wouldn't go into multiple different areas of the code and probably introduce even more bugs when you could go into the portion of the code that is very obviously causing this behaviour and fix it there with a smaller change.

The roll jump lock is a deliberate design decision.

 

Except that SolidObject and its cohorts also call Sonic_ResetOnFloor, which is shared with the ground collision code, and that's where the flag is cleared. So no, it's not handled separately in this case. It really is as simple as setting the flag when jumping from rolling, checking during the air control routine, and then clearing it in Sonic_ResetOnFloor, and that's how it is in Sonic 1.

Here's what I think.

I would say the normal ground and air controls is moreso designed for the platforming side, while the rolling state is designed for the faster paced sections, where you are making the most of the physics engine. The normal ground and rolling states use their own routines, but the air and jump states share their functions with each other. They couldn't have just checked the rolling flag, because that is set when jumping, so it would lock the controls when doing a normal jump. So, they put in an extra flag to specifically indicate a jump from rolling.

I would argue that if the pit that Sonic fell in was larger and more spacious, it would probably have been addressed. But, in my opinion, doing a jump exposes the issue more blatantly. Now, I am not arguing that locking the controls was a good fix. In fact, it's a pretty shitty one, especially since you said it doesn't even work when rolling off a cliff, but I do think it's possible they just simply forgot about that case, or didn't think it was as bad as the jumping case. I don't think it's really unheard of for programmers to sometimes think of gross hacks over a proper fix (even if the proper fix is more simple).

 

I'm not really getting involved with the classification of Bug vs Intention, but I would like to address the whole Yuji Naka thing.

I think it's important to segregate your biases of the programmer and his work. I don't really like Naka much, but I won't let it shroud my judgement.

You guys could (as a hobby) write an engine to be perfect; then as you add more game elements, it begins to disturb your optimum engine, then your choice is; do you rewrite the engine from scratch with the changes in mind, or do you just put in a flag and risk it being a bit dirty? These game developers are under time restraints, they likely don't have the privilege of such a choice. Career, competitive business, and money are all at stake here, it's no joke.

Incorrect conditional branching (signed vs unsigned) is not an indication of a programmer's competence, especially if the differences only occur in extreme circumstances you're never likely to see. Mistakes happen while under pressure too, in the real world you have to be somewhat industrious and messy, this is why industrious people succeed. Obsess over the code too much and you'll lose the worm to someone else.

The point I'm making; it's easy to criticise the professionals when you do the hobby equivalent with unlimited time, resources, and freedom, and no-one else over-watching. The state of the code can be used to debate whether bug or intention, not problem with that, but not to debate competence. You need other factors to debate competence, not just the state of the code.

 

My dad has told me multiple times that in many cases, "it doesn't have to be good, it just has to be". Also, perfect is the enemy of good enough. For all of the mistakes made and questionable choices, the code runs as it's supposed to and with minimal game-breaking errors.

 

For the record, when I said Yuji Naka wasn't above dirty hacks, it wasn't necessarily meant to be an insult to him, but rather a point that he is human and can make mistakes, just like everyone else. Especially with deadlines and planning getting in the way, I really doubt Yuji Naka put in the effort to make sure the physics engine didn't have any hacks or flaws in its logic. I think at the very least he wanted the engine to at least function without glaring issues, which is why I find the roll jump lock being a hack to prevent weird/limited movement while in the air when jumping after rolling at a high speed to be believable. I agree it isn't a great fix at all, but it is entirely possible that was just what was quickly decided on in a flash and was left as is. It really isn't entirely fair to judge the code as if Yuji Naka had all the time in the world to make sure everything was perfect in some way, which is what I meant when I said he wasn't above dirty and quick hacks.

However, to say that he was incompetent is just not right. Even with the flaws, the engine he developed was clever and was very much helpful for establishing Sonic's own identity from the rest of the mascot platformers of the time. It did its job well. We here have the benefit of hindsight and more free time. We are, in a sense, spoiled. We will never truly know what it was like in Yuji Naka's shoes, all we can do is make educated guesses. For all I know, I can be very wrong, and perhaps it really was a design choice, but at the moment, I do stand by what I said, and I do believe that just because a certain solution might seem more simple/obvious, doesn't necessarily mean that that was what came to Yuji Naka's mind at the time he was programming Sonic 1. IMO, the only reason we really see the solution of not accelerating if past top speed as a better and more simple solution is because that was what was done in Sonic 2, so we have that to refer to... but that's just it, it's only my opinion.

 

As crazy as it is, it's true. Here's an image from the guide overlayed with a vanilla ROM.

Although it's not the emblem that's moved up it's the background. During the title screen the emblem has no vertical scrolling applied to it.

 

I have no idea how that would even happen. Furthermore, I compared a vanilla REV01 ROM with a hex-edited version in Exodus, and no relevant differences could be found.

 

Yeah, uh, I followed the guide and I didn't get that result.



Though, it's a bit messed up, because the current GitHub disassembly already has the fix bundled in, which is activated by enabling FixBugs, so the added code is redundant. I went ahead and updated the page to account for this, while remaking the Hivebrain 2005 version.

 

Glad the Hivebrain version was added back... I get that it's old but wiping it does more harm than good. Still annoyed that it got wiped from the Spindash guide.

 

Okay, I believe I found out what was going on. The screenshot on the wiki is in REV00, which is what the 2005 disassembly is based on, but the GitHub disassembly defaults to REV01, and the Y position of the background for Green Hill Zone was changed between revisions in the deformation code.

REV00:

Code (ASM):

1.                 move.w  (v_screenposy).w,d0
2.                 andi.w  #$7FF,d0
3.                 lsr.w   #5,d0
4.                 neg.w   d0
5.                 addi.w  #$26,d0

REV01:

Code (ASM):

1.                 move.w  (v_screenposy).w,d0
2.                 andi.w  #$7FF,d0
3.                 lsr.w   #5,d0
4.                 neg.w   d0
5.                 addi.w  #$20,d0
6.                 bpl.s   .limitY
7.                 moveq   #0,d0
8.  
9.         .limitY:

So yeah, the guide is not at fault, just some confusion. I removed the "bug" part of the guide, and instead put in a disclaimer for the screenshot.

 

At the same time, I feel the real problem is that often, there ends up being redundancy between the two sections, so I could see how merging them might be beneficial.

Are the credits on the top intended for people following the guide who would have to give credit to those using the guide? Otherwise, I would think that the page history would be enough to indicate who wrote what.

 

Those credits should be taken carefully in general, I seem to remember that I'm credited for a guide I didn't even write, so it's possible that more of them are inaccurate.