Sonic 1 Bugs

This makes a lot of sense. Nice guess, Upthorn.

 

Good point... but does it mean that every enemy and the spikes have their own separate "hurt Sonic" routine? Or are the spikes the only object that have it inside its own code? It would make more sense if it just played the "spike hit" sound and then called the same routine the enemies do.

Can somebody please post a quick comparison between the relevant code in both cases, so we can see the differences and what had to be changed for Sonic 2?

 

I wasn't even aware that they were leaked to the public. Who obtained them, and when?

Erm... You can't call the routine that the enemies do because that routine is meant to allow damage from all sides, while spikes inflict damage on both top and bottom. There's a bunch of collision types that can be defined in the SST, each with a different player reaction type. You can check more into it here.

(The page is for Sonic 2, but it works the same in Sonic 1 as well)

 

Bump... I have never heard of that database either. Does anyone know about it, or about where it is? I'd love to see it to be honest.

 

It used to be up on Cult, dunno if it still is.

Though, even though it is listed in the database, it's not like it was written by Naka. So we really don't know if it was a bug, or just considered as a bug after S2 was released.

I mean, with all the testing they did in S1, how could they miss something so obvious like the spike bug? It's not like it would be hard to fix.

 

I think the mere fact that it was fixed in a subsequent revision of the engine clearly identifies it as undesired behavior. Wouldn't you? They made no changes to the game otherwise -- just cleaned up what they considered to be bugs. The spike issue was one of the things changed. Therefore, someone must have identified it as a bug. (Actually, we know someone did, because it was included in the bug database for the game.) So, we have to refer to it as -- a bug.


So, the question remains, why would they have "left it in?"

Consider that they had some really nasty, obvious, difficult bugs to work out prior to the rushed release date. Those were the only ones they had time to fix. Everything that was low/medium priority and left the game playable without issue had to remain until the next revision.

They left the Motobug that is situatied in the middle of nowhere in GHZ, they left the "jumpwalk" bug when next to a rock in GHZ, they left the big ball in GHZ's debug mode, and they missed a few other things. The testing database reveals a plethora of problems they had before release. Not all of these were addressed, including the spike bug.

Until the next revision. Then, these bugs dissapeared.

If it were desired behavior, Naka wouldn't have agreed to fix it.

If you believe it was intentional, you'd have to believe that a tester identified it as a bug, Naka claimed it was desired behavior, they had a huge argument about it, Naka lost, and Naka was forced to change his code. Out of all the possibilities, I think this is the least likely of scenarios.

Facts:
- Bugs existed in the first revision of the game.
- Game testers find bugs based on discrepancies between the planned design of a game and the current implementation.
- Game testers identified the spike issue as a bug.
- Bug databases contain only bugs.
- The spike issue was listed as a bug.
- Game revisions remove undesired behavior (bugs) from games.
- The spike issue was removed during a revision.

Conclusion:
The spike issue was an official bug.

 

Wasn't that bug list from Sonic Mega Collection?

Facts:
-That bug was removed midway through the development of Sonic 2 (you know, it's still in the Sonic 2 protos)
-The only Sonic 1 "revision" that was put on cart as far as we know (the Japanese edition), had tons of different stuff but kept the spike bug.
-It was just hacked out (not recompiled) for Sonic Mega Collection, from where the bug list originates.

Conclusion:
???

 

Apparently, they've lost the source. If they still had it then Sonic Genesis would be tons better, but it was written from scratch. Also Sonic Mobile or whatever it was was written from scratch as well.

 

Someone has to have the code. Like, a lonely programmer or something. Plus, as it was recently proved, Sonic Advance was largely based on the S3K code, so they must at least have S3K (which would mean they also have S2). S1 is a different case, because it was developed elsewhere, but things happen.

 

Does it really matter? It was still removed with the intent of fixing a bug (otherwise there would have been no reason to do so).

1. Considering it took them long enough to fix the bug in the original Sonic 1 (but note that that STILL FIXED IT), I'm not surprised. Seeing as the prototype was not meant to reach the widespread public, there wasn't much reason to fix it immediately. Besides that, Sonic 2 was built off Sonic 1 Jap, so the spike bug would be carried over from that.

2. It didn't fix any bugs, all it did was add new graphical effects. They probably weren't made aware of any specific in-game bugs, since the game was already on the market in the US.

3. Why does it matter if it was hacked in Mega Collection? It was still a bug specifically marked to be fixed, and it was.

Also note that the spike bug was fixed YEARS before, in Sonic Jam, when you enabled Spindash mode for Sonic 1. This fixed the spike bug, as well as added dust for when you skid.

 

They DO still have the source, guaranteed.

I decompiled Sonic Mobile, and all of the core game logic is directly ported from the original assembly! I alerted Stealth, who looked at the decompilation and came to the same conclusion. They use a ton of classes and arrays to mimic the different RAM areas, but the entire game is a statement-by-statement port (except for the obvious parts like the sound and rendering engine) to the J2ME platform.

Haven't you ever played this game? It's 100% accurate, aside from it being choppy, and from the fact that the resolution of the levels and collisions had to be reduced by half. (Which, programmatically, is a pretty amazing feat.)

The "VRAM" that they simulated with PNGs seems to be directly from SEGA as well, as MGZ's VRAM set contains the old UFO tiles!

With this in mind, it might be worthwhile to contact some of the developers for Sonic Mobile and see if we can befriend one enough that he'll trust us to violate his NDA -- and perhaps talk a little about exactly what SEGA supplied them with.

 

Well, for whatever reason, when Sonic Mega Collection came out, Sega ported Gens to gamecube, and claimed to have lost the original Sonic the hedgehog source.

 

I don't recall that. Proof?

I know that before SMC was ever made, people have been saying that thay have lost both the S1 & S2 source code. I've never seen any proof of this.

 

I thought they developed their own emulator, and used SMC to promote it to other developers. That's what I read from PACHUKA's posts on Sonic CulT anyway.

EDIT: relevant link

 

I don't remember where I initially read that it was Gens, but Stef (Gens' maker) confirmed that Sega negotiated for a special license from him. All they actually developed themselves was the GUI. As further evidence I would point out that the Sonic Mega Collection has the exact same errors in sound emulation that Gens does. The voices cutting off in Sky Sanctuary are particularly easy to catch.

The reason Sonic CD wasn't included until Gems collection is because they couldn't get Gens' Sega CD support working properly on GameCube by the time Mega Collection was supposed to ship.
Having worked with Gens' source I can testify to the fact that its Sega CD and 32x support implementations are pretty highly spaghettified code.

 

All PC emu-type games are Gens modifications. It's easy to see that because Gens uses the Starscream 68k core, which needs the memory to be byteswapped, so in the emulators memory, everything is byteswapped. Other than that, Stef is usually credited in the 'Special Thanks'.