I just read through a bit of the physics guide on the wiki in an attempt to understand the controls better, and I now suspect that the speed cap wasn't by design, but rather oversight. Obviously, the purpose of the speed cap is to ensure that the player travels no faster than 6 pixels per second, but the problem is that it also caps off movement when the player is traveling faster than that when not using his own abilities (such as using a speed booster or horizontal spring). It's only capped off when the player is using the controller to move the direction that they are already going, even though the player was meant to travel faster than 6 pixels per second by design. I mean, this would make it a bug due to being applied to situations where the player is supposed to be moving faster than their max speed, right? I ask because I'm inexperienced in these matters and figured that others with more experience dealing with the engine might have a different answer than me.
The fact that it was partially removed in Sonic CD and 2, and then totally removed in 3&K, leads me to believe that it is behaviour that was undesired by the original Sonic Team. So I would say that yes, it's a bug. Incidentally, when I programmed my first platformer engine years ago before studying Sonic, it was a bug I had. It seems like something that comes from code that's not that well thought through. EDIT: You're right, my bad.
Not quite totally removed in Sonic 2. Remember, they went ahead and fixed the ground speed cap, but the air cap is still present. IMO I think this further supports the belief of it being a bug. They went through the work themselves, of fixing it, and only got it half right... aka ANOTHER oversight.
I was never sure if it was a bug or not. During the years of the making from S1 - S3K, the levels got longer, and faster, and maybe that's why they started to remove the speed cap in the later games?
I'm pretty sure it was by design. In prototype versions of Sonic 1 it was said that sonic moved much faster, but this caused problems so they slowed him down, I think the sonic 1 speed cap was the result of this. Also extra code is required to implement a cap on the speed, so this code was put in deliberatly, for one reason or annother.
So that would make the speed cap not a bug, would it? While I have not hacked Sonic games (yet), if there is code for it, that would mean it would be an intentional feature. I do find it interesting that it's not entirely removed in Sonic 2, perhaps to make the game more appealing and faster they removed the cap in part, though how do we not know that the air cap in Sonic 2 is not intentional too, after all some of the earlier levels are kinda short. Also if anyone can answer me this question tell me, what's the difference between the somewhat removed speed cap in Sonic 2 and Sonic CD, is it roughly the same?
This is wrong. It actually requires less code. Let me explain. Sonic can accelerate up to 6 pixels per step under his own power. The code for this is like "while the player holds in a direction, add to Sonic's speed. If it's greater than 6, make it 6." But Sonic can accelerate for other reasons. Most often by running or rolling downhill, but also from being hit by springs. In cases like this, he can reach speeds well in excess of 16, even sometimes surpassing 20. But, if he's already moving that quickly, and then you press in that same direction, the "if it's greater than 6, make it 6" code runs. It takes more code to remove the speed cap, because there has to be an extra check preventing him from accelerating when the button is held if he's already running faster than 6. This is clear from the guide on the wiki. So, "speed cap" is a misleading term, because Sonic's speed is NOT limited, not even in Sonic 1, and he can be accelerated indefinitely from outside forces. The "speed cap" does not slow Sonic down, prevent problems with the engine, or anything of the sort. Removing it does not speed Sonic up. All it does is prevent an ugly unexpected halt in Sonic's motion when you press in the direction he is running when he is running quickly. Finally, you can see for yourselves that Sonic isn't actually slower in Sonic 1, despite the popular misconception. If you don't touch the D-Pad and cause the speed cap bug (yes, it's a bug), Sonic will go crazy fast, especially in Starlight Zone.
The speed cap design/bug has never really been much of a problem for me. Whenever I get Sonic going at high speeds, I purposely make him roll by pressing/holding down. This way, he seems to gain more speed and able to destroy enemies in his path. Whereas running, he is vulnerable. Pressing/holding down doesn't seem to be affected by the speed cap either. So, this may be another reason why it could be a bug. as it only applies to when pressing/holding left/right. Seeing from what I've seen in this topic so far, yeah, I'm leaning to think it's more of a bug than my original thought.
Thank you for clearing that up Mercury, I was wondering about Sonic's speed when it comes to other means (such as springs and slopes). This is a little off topic but what's the difference between the speed of other characters in Sonic 2 and 3? I think that Tails moves just as fast as Sonic in Sonic 2 but I'm not sure, and I'm pretty sure that Knuckles moves slower then Sonic in S3&K, but is Tails just as fast as Sonic in S3&K or is he a little slower?
It's only if you hold forward when being boosted by a spring or mechanism, otherwise with you don't the speed cap won't apply. it is entirely an unecessary feature in those circumstances just because it works in odd ways.
When not Super/Hyper, everybody handles identically. The Physics Guide should have all this info, but the wiki's acting up again (for me at least).
I would also agree that it is a bug because of the reason said above "The fact that it was partially removed in Sonic CD and 2, and then totally removed in 3&K, leads me to believe that it is behaviour that was undesired by the original Sonic Team.", additionally, with sonic moving at such a fast speed and then holding the direction button, only to have sonic change immediately to the maximum speed rather than slowly, only further suggests that it is a bug. Though technically it still falls under the same issue we've had with the spike "bug", it has been improved over the series, but that doesn't mean to say it wasn't intentional at one particular point in time, is there a possibility of actually "asking" the ones involved in this "bug-fix" so we can 100% confirm it?
Really, wow...I really should read the physics guide. But I'm glad they give characters their own speed and different attributes in later games like Chaotix and the Advance games. Also I agree with MarkeyJester on asking those involved, any names exactly on who to talk to though.
aah! I see. Seems I didnt quite understand its nature, I thought we were talking about a limit when accelerating from a stand still. It does sounds more like an oversight rather than a bug though, a bug implies the code isn't behaving as intended. As it stands the code was doing what they wanted that code to do, it was just being applied in incorrect situations.
By that definition, it seems more like a bug to me anyway. While true, it's working as intended on its own, it is being applied to situations that it apparently wasn't intended to be applied to, so as a whole, things don't work as intended.
It would be very odd for this to be an oversight for two reasons: -Making Sonic run down slopes was the "main new thing" in this game, something that everybody in the team was constantly doing, so it's very unlikely that nobody would have noticed anything odd about it during the whole development cycle. -The speed cap doesn't happen when rolling, so they would have been able to "fix it" in no time, had they wanted to. In my oppinion, just like the way you can't control a roll-jump (not a bug), this might have been intended by design as another way to differentiate the states of "Sonic on foot" (having precise control at all times, like a faster Mario) and "Sonic rolling" (way faster but hardly controllable). Is this really the way it's coded in Sonic 1? How about Sonic 2 or Sonic CD? If I understand correctly, Sonic's code in Sonic CD was based on but not directly borrowed from Sonic 1, right? In that case, Sonic CD having a speed cap would make it deliberate, unless they made that same "newbie developer" mistake again.
So I guess that begs the question as to what happens if someone creates a level that's purely just 1 big hill from beginning to end (just for the fun of it - including stuff like badniks on the way down, and something at the bottom perhaps)? When Sonic goes off-screen with going so fast, does he go through badniks (similar to the infamous Sonic 1 bug when looking down and pressing jump at a particular point skips half the level) or will we hear them getting destroyed on the way down?
It doesn't happen when rolling because the speed cap can only manifest when the player tries to accelerate voluntarily, which is not a choice they have whilst rolling. So I fail to see how this is relevant, much less how it vindicates Sega as having intentionally implemented the cap. So, yep, consider me firmly in the bug/oversight camp. I'll check the SCHG's implementation after this, but just for the sake of thinking aloud, I imagine the code needed would be something like… Code (Text): if (control == left || control == right) { if (speed < max_speed) { ++speed; } } Not… Code (Text): if (control == left || control == right) { ++speed; if (speed > max_speed) { speed = max_speed; } } Really, the latter method is quite obviously – even to a hopeless non-programmer like myself – wrong in terms of logic, efficiency, and aesthetics. In conclusion, SEGderp.
My impression was that the speed cap was in place to stop Sonic running through scenery. This happens from time to time in Sonic 2's Chemical Plant Zone (there's a half pipe you'll run through, rather than up), and I'm sure I read somewhere that it was due to the processor not being able to keep up. But then again, Chemical Plant Zone is the only level I can think of that ever exihbited this behaviour (and there isn't a speed limit to stop it there) and that might be because of some other factor. I do think it's useful to have some sort of speed limit in place though, otherwise it's open for abuse by level designers.
