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. Antheraea


    Bug Hunter Member
    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.
  16. It seems that there haven't been many discoveries here recently. Allow me to change that!

    Within the level size arrays of this prototype, there remains unique data for each Act 4. Usually, they should be duplicates of Act 3, but since they were laid out, the levels have changed quite a bit.
    Mainly, the differences are within the X boundary (where the level's told to end). Some of it remains in the final, though I haven't seen anyone discuss it yet.

    Starting off, Green Hill's Act 4 has the X boundary of 2ABF. Normally in Act 3, it's set to 2960. This makes the level end right at the capsule.
    When the boss is defeated in both the proto and the final, the camera scrolls to 2AC0, which is only a value higher. This value remains in the final game.

    Labyrinth's Act 4 X boundary is 1EBF, identical to Act 3 in the prototype. Of course, both Act 3 and 4's X boundary would change in the final game, as Act 3's level design heavily changed, and Act 4 became used for Scrap Brain Act 3.

    Marble's Act 4 X boundary is 16BF, which is slightly further than Act 3's 163F. This doesn't enter the placed boss arena, which may suggest this is from a point where the arena simply wasn't in the level yet.
    This value remains in the final game.

    Star Light's Act 4 X boundary is set to 3EC0, which appears to be a default [check Clock Work's section]. Considering the X's placed in the level select, this level may have not existed within earlier phases of development. This value remains in the final game.

    Sparkling's Act 4 X boundary is set to 29C0, which is interestingly smaller than Act 3's 2EC0. This doesn't appear to line up with anything placed in the level, so it may be a remnant of an earlier phase of development, which had a very different layout for Sparkling.
    The final game changes this value to the prototype Act 3's 2EC0 while changing the actual Act 3 to 2C00.

    Clock Work is set to 3EC0 in every Act, suggesting it was a "template" value.
    The full set of values are:
    Code (Text):
    1. $0004, $0000, $3EC0, $0000, $0720, $0060
    This value remains in the final game's Act 4.

    Finally, Zone $06 (ending in the final) has every X boundary set to 2FFF, which appears to be a secondary default. This value remains in the final's Act 3 and 4.
    The full set of values are:
    Code (Text):
    1. $0004, $0000, $2FFF, $0000, $0320, $0060
    That's it! This may tell a bit about what these levels were like earlier in development.
    • Like Like x 6
    • Informative Informative x 6
    • List
  17. Nik Pi

    Nik Pi

    Sonic 2: Archives
    It's heckin' necrobump, but thank you. This thread looks so nostalgic for me..
    Also Sparkling's another level size looks interesting, knowing that the game has unused layout data inside.. is it was the first build where are it was changed?
  18. JayKuriN


    Defeated Dreamer Member
    Necrobump? Let me add a bit more!

    Allow me to talk about how thirsty I am.

    There's multiple leftover Hint routines left over in the prototype. Two discrete and one implied, (You'll see in a bit what I mean.)

    Markey touched on it briefly, but there's a DMA transfer for water in the effective H-Int code that's there. However, this does not load from ROM, rather, it loads from RAM, from the duplicate palette reference for palette cycling. If H-int is enabled, a noticeable but subtle effect can be seen where palette cycling data is killed midway down the screen.

    But if you are to load a separate palette over that region, or change the DMA origin address, you get a result very similar to that of the final game's water:

    It can be controlled, and the routines for handling this are called during normal gameplay, but H-int is disabled by default.

    Right underneath this code is another H-int routine that can be easily restored. What it does is swap the Plane B and Window plane nametables, and also swaps the sprite table with.... itself... which causes noticeable sprite tearing.

    What this is intended for is currently unknown, but there's a likely chance this is an early version of the dithered water pattern once mentioned in an interview (One that I can't really recall right now to source).

    Using this, I sent some tiles to the window nametable location, went into labyrinth zone and:

    But that's not all. There is a third, insanely more interesting routine left over in this prototype. There is no Hint code left for it anymore, but the data it generates appears to be used for a routine in Hint.

    At 0x3018 in the prototype, there is an early version of LZWaterFeatures. The code that handles the Hint registers is called 0x10 bytes under it. 0x3018 generates a set of VDP commands for the window plane size to the Nemesis GFX buffer. It appears this would have been called every frame to generate a table for sending to the VDP each line that Hints are triggered. The below video demonstrates what this might have looked like, however it's not perfect (Credit to RivetDev for partially restoring the routine originally):

    So yeah I don't think I'm going to die of thirst very soon. If anything I'm going to drown.
    Last edited: Feb 14, 2023
    • Informative Informative x 21
    • Like Like x 2
    • List
  19. Diablohead


    Indie dev Oldbie
    Near London
    Cool to see how the water could have been with those tricks they were testing out, seems like even with the old water they wanted to give it some sort of ripple or effect and not just an static overlay.

    Now I wonder how those air pockets underwater would have worked or if the water tiles would go invisible in those areas.
  20. Mookey


    It's interesting to see the dithered water layer with the proto background; makes a lot more sense if you were only meant to see the background above water, and the overall darkness of it makes the lack of a background while underwater less jarring imo.