don't click here

Sonic the Hedgehog (Prototype)

Discussion in 'General Sonic Discussion' started by drx, Jan 1, 2021.

  1. Hez


    You know, I don't think it does but looking at that level layout makes me think that at one point it might have had level wrapping in mind. Even the background would work with wrapping.
  2. Sonic Hachelle-Bee

    Sonic Hachelle-Bee

    Taking a Sand Shower Tech Member
    Lyon, France
    Sonic 2 Long Version
    If I remember correctly.
    Even without vertical wrap, if the top row of 128x128 is made of solid tiles, falling down to the bottom of the level doesn't kill you. You are actually standing on the top row.
    With that in mind, there is still no excuse for the spikes. The top row should have been empty.
  3. Dek Rollins

    Dek Rollins

    size of a tangerine Member
  4. Lostgame


    producer/turnablist. homebrew dev. cosplayer. Oldbie
    Toronto, ON
    The O.I.C.
  5. Hey, not sure if this has been documented yet, but there's an incredibly easy vertical camera wrap you can trigger in GHZ 1 just by jumping to the left towards this ledge in this blurry screenshot I took with my phone (I was playing on 3ds lol). It's near the top of the map just past the loop. Iirc, this is also the same spot that the camera can't keep up following sonic as he jumps down making it incredibly easy to die. 20210422_143751.jpg
    Edit: it takes longer for sonic to stop when he's skidding too. Is that known? Or am I just wasting my time now lol.
    Last edited: Apr 22, 2021
  6. muteKi


    Fuck it Member
    I think from a design perspective the idea that the spike bug (I will acquiesce that calling it a bug is fine given the way the code creating it is structured) wasn't caught during testing is weird, given that most of the first spike placements are spaced exactly the hurt knockback distance apart. If this was behavior they needed a quick fix to prevent happening in, say, GHZ1, surely the answer would have been to space the spikes farther apart?

    I am curious if any of our more advanced 68k assembly spelunkers have any idea why the spike hurt logic is different. Is it just to handle the different sound effect?
  7. Nova


    Forgive me if I'm wrong but this post from a couple pages back explains it.
  8. SystemsReady


    I Have No Idea What I'm Doing At Any Given Moment Member
    The Twin Cities
    trying to not fall asleep while writing Selenium tests
    don't forget, Sonic 2 started out being an edit of Sonic 1. the first prototype even has Sonic 1's header (and thus can unlock the full Blue Spheres), because they basically just messed with a Sonic 1 ROM to get things set up - and this includes things like the "speed cap" and debug mode being identical - and they just kept building on that while removing Sonic 1 assets.

    It could totally be that in the face of much, much worse behaviors, they took a long while to fix it because they needed to prioritize those instead. Bugs were being fixed down to the wire for Sonic 2.
  9. MrLordSith


    About a month ago, some unused code in the prototype was found where the code for dying is located. It doesn't work at first since the game asks if you're holding A B or C, and if so, it branches to another function which goes to rts, and if you're not holding any, then it asks if you're holding A. You can see why it doesn't work, since that part of the code doesn't make any sense and breaks everything.
    So, by removing the first part of the code to make it execute/work (removing the part where it asks if you hold A won't make it work though), it results in what seems to be some weird "respawn" system as seen here:

    In this video, I show what the code does and how you can "cheat" or "break" this strange "mechanic".
    Sonic will lose his rings normally, but if he has no rings, instead of dying, he will reappear at the last position he was at before dying. If you were to fall into a pit or get crushed by something, you would lose all your lives as seen here:

    You can also attempt to press A while dying (which is why the 'A' input code was there) to restart the level, but it's hard to achieve, and doesn't always seem to work.
    To me, this seems like it was meant for testing and/or debugging since it's very simple and there doesn't seem to be any thought put into it whatsoever, and by looking at the code, it seems like it was meant to make you respawn if you pressed a button, which does seem like something meant for debugging to be able to test things. However, that is just speculation and are just my thoughts on this, so don't take it as fact.
    • Informative Informative x 17
    • List
  10. saxman


    Oldbie Tech Member
    Great find!

    Seems silly they wouldn't just have the player be invincible if it was for debugging. Seems likely to me that they weren't sure if you should restart where left off, or start over. Therefore, they added controls to try out both scenarios. But that is also just speculation.

    To further that theory, it could explain why lamp posts were such a late addition.
  11. Violet CLM

    Violet CLM

    So that's why there were no checkpoints.
  12. Brainulator


    Regular garden-variety member Member
    I wonder why they couldn't just prevent you from losing lives should you respawn...
  13. RDNexus


    Maybe it was a bit complex for the console system, at the time?
    Or lack of coding experience to manage to overcome that issue?
  14. _Sidle


    Debug mode typically lets you cheat death by going in and out of the object selector while in the falling-offscreen animation, so this prototype feature would be rather redundant for that.

    It being a restart-or-resurrect system in place of checkpoints seems to make the most sense, even getting inv-frames during that Motobug demonstration.

    EDIT: Sonic 1's Debug is different than I remembered, cheating death via debug simply doesn't exist in Proto/REV00/REV01. Very obvious blunder on my end, should've done a quick check beforehand. Incredibly sorry!
    Last edited: Jun 12, 2021
  15. That function did not exist in Sonic 1 at all.