ReadySonic

Discussion in 'Engineering & Reverse Engineering' started by Mercury, Jul 29, 2011.

  1. Mercury

    Mercury

    His Name Is Sonic Tech Member
    Copypasta from my blog:

    HOME PAGE

    ROM
    SOURCE

    More likely than not this will see no updates from me, as I've pretty much given up hacking in order to concentrate on fangames. Nonetheless I hope someone can derive some enjoy from it; the concept met mixed but mostly positive responses when revealed in the Tech Members Lounge months ago.
     
  2. FeliciaVal

    FeliciaVal

    Member
    well, this is embarrassing :/ I tried posting something but never showed up...oh well, I'll try reposting it when the forum works better
     
  3. FeliciaVal

    FeliciaVal

    Member
    well finally I can post regularly. I wanted to say that thank you very much for this, it's very fun to play a hack with the super peel-out already implemented. But I had a bit of trouble trying to open the sprites on Sonmaped. Everytime I try to load them, the program crashes and I can't even see them. Is there any fix to this? I'd like to try this dissasembly for a future project but I can't due to this
     
  4. Selbi

    Selbi

    Impaled with Extreme Prejudice Member
    1,482
    0
    0
    Northern Germany
    Sonic ERaZor
    I'm not gonna lie, I never even heard about most of the bugs you listed, let alone experienced them. Good to see they are all fixed, though, of course. :)

    But I'm curious, how did you fix this on the debug mode:
    I honestly have no idea how to fix that, because it annoys the hell out of me everytime I had to use the debug mode to place shit.

    EDIT: After reaching the "Elective" Mods list, I noticed that you included two features, that are often being seen "overused and shouldn't be used by everyone", which are the Super Peel Out and the Centi-Seconds timer. I personally don't have that much of a problem with it, but I'm sure other's have.
     
  5. MoDule

    MoDule

    Tech Member
    309
    0
    16
    Procrastinating from writing bug-fix guides
    Funny thing, I'm working on something similar for Sonic 2 at the moment, as some people might have already guessed.
    Like you said, it's amazing how many flaws you can find if you just spend enough time looking.
    I'll definitely play this later now.
     
  6. Mercury

    Mercury

    His Name Is Sonic Tech Member
    I've never used SonMapEd, someone else would have to help with that.

    Here's a quote from my mini-tutorials for each fix which I'm procrastinating from finishing and posting:

     
  7. JcFerggy

    JcFerggy

    Do you want to taco 'bout it? Member
    1,298
    5
    18
    Nova Scotia, Canada
    GoldenEye: Source, Other Stuff
    Funny how you fixed the sprite oddities with the spring and spinning, yet Sonic's socks are still skin colored when running.

    Aside from that this is awesome.
     
  8. ICEknight

    ICEknight

    Researcher Researcher
    This is pretty cool, but I've noticed some inconsistencies when classifying those fixes. It says that:

    But then, these sound more like personal preferences:
    With that said, I also love how you've added all those "elective mods". Nice work. :)

    EDIT: Just a small suggestion for this one:
    Wouldn't it make more sense to make them react to the objects' solidity, as Sonic does?
     
  9. Mr Lange

    Mr Lange

    A wise guy eh. I know how to DEAL with wise guys. Member
    1,286
    2
    18
    The Land of Waldos
    Sonic Utopia, Sonic Overture
    This is great. Just by itself this hack is loads of fun.
    You even added the Sonic CD spin roll method, which has made me a complete person.
    You added spindash and peelout, which is nice, and even a walljump, which I found somewhat unusual.
    I can see not adding insta-shield or homing attack since that's more extraneous, but I'm surprised you didn't add midair rolling, which has become much more of a fundamental ability, especially considering it was in Triple Trouble. Any reason why you didn't add that, or were you planning to?
     
  10. Mercury

    Mercury

    His Name Is Sonic Tech Member
    Simply put, I was too lazy to do the harder method. :ssh:

    IMO the HA breaks classic Sonic gameplay, so I wouldn't have added it. I love the insta-shield and midair roll, though - I did plan on adding them, but then again there's a huge list of things I was going to add before I decided to concentrate my efforts elsewhere.
     
  11. Cinossu

    Cinossu

    Administrator
    2,820
    8
    18
    London, UK
    Sonic the Hedgehog Extended Edition
    Lots of lovely fixes in this, and going through your code to see the changes that I missed for things is a wonderful way to get me back into recognising my way around the Sonic 1 ROM (I've been doing other bits and pieces programming-wise for a while now, so this is a nice way to reacquaint myself).

    One "bug" that's in this, though, that I would love to find a fix for myself and never could, is when using Chunks in ROM, you can't go above the top of a level in some zones. While this may not seem like much, Spring Yard Zone had some lovely shortcuts that made use of this, and Star Light Zone always has a weird start-stop thing going on with it.

    I've tried padding the both sides of the uncompressed chunks, up to $800 bytes, but no change occurs. I'm curious if anyone knows how to solve this little niggle of a bug.
     
  12. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,138
    0
    16
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    When you are above the top of the level (negative y), you are effectively colliding with terrain on the bottom of the level -- levels "wrap" vertically above the top of the level even in levels that don't vertically wrap.

    For an example of a place where this happens: go to '_incObj/sub FindNearestTile.asm'; check the following code, right at the top:
    Code (Text):
    1.         move.w  d2,d0       ; get y-pos. of bottom edge of object
    2.         lsr.w   #1,d0
    3.         andi.w  #$380,d0
    This performs a level wrap of the object's y position. A position of (say) -100 in d2 ($FF9C) becomes $7FCE then $380, the same as position of (say) $700 would become. Since this is used (after right-shift of 8 bits) as an index into the level layout, being at the top is equivalent to being at the bottom in terms of collision with tiles. Note that I am not saying that changing the code here will completely fix the issue -- there are probably other locations that need to be changed to fully fix it. Moreover, fixing this in a way that does not break vertically-wrapping levels is going to be tough.

    If the level already had a height close to the maximum height a level can have in Sonic 1 ($800 pixels, or $8 256x256 blocks in vertical height), there isn't much padding you can add at the end of levels to prevent this effect (for example, LZ1,LZ2, LZ3, SYZ1, SYZ3, SBZ1 and SBZ3 are all at maximum height). For other levels, you can pad their data as if they had maximum height with collision free 256x256 blocks to replicate the effect from a "normal" RAM layout.
     
  13. Cinossu

    Cinossu

    Administrator
    2,820
    8
    18
    London, UK
    Sonic the Hedgehog Extended Edition
    The only reason why I'm curious as to why this happens in this way, and this alone, is that it only happens when adding in the additional pointer to the 256x256 chunks location, not the level layout location, and it does NOT happen when just using the original code. That's why I'm curious as to why it's not working. I get that it wraps around from top to bottom, and bottom to top, but it doesn't solve why it doesn't happen when 256x256 chunks are decompressed into RAM, only when loaded directly uncompressed from ROM.
     
  14. MarkeyJester

    MarkeyJester

    ♡ ! Resident Jester
    It's because in RAM, the layout space is 100% the size of a full possible layout, all the possible space is allocated, empty and padded out, there as in ROM, if the layout isn't 100% padded out (which being S1, most likely won't be), then the engine will extend "passed" the act 1 data into whatever data is after it in ROM (most probably Act 2 layout somewhere).

    EDIT: fixing spelling, my eyes are hurting at 4am
     
  15. Cinossu

    Cinossu

    Administrator
    2,820
    8
    18
    London, UK
    Sonic the Hedgehog Extended Edition
    Again, this would make sense to me if it were the level layout that were staying in the ROM, but it's not. It's the set of available 256x256 chunks, the file in "map256_u". This is what I don't get. If I'm being thick, then please explain for the stupid in me. :s
     
  16. MarkeyJester

    MarkeyJester

    ♡ ! Resident Jester
    Ah, I see what you mean, I misread (I.e. 4am, etc =%), the only theory I can generate here at this hour is that it "may" be where a previous layout (that were large enough on the Y axis), still has it's end part of the layout stored in ram, with a new level with a more smaller layout not overwriting it all, if the previous layout that's still in RAM has chunk ID's at the bottom of the layout that are higher than the number of chunks in the current level, then it'll read whatever data is passed the uncompressed chunks in ROM, thereas in RAM the data after the chunk space is different (maybe even different enough to pass itself off as clear/empty chunks at the bottom of the layout, if not graphically, then most likely from a collision sense).

    Again, this is just a theory, I might look into this later myself for more confirmation.
     
  17. Cinossu

    Cinossu

    Administrator
    2,820
    8
    18
    London, UK
    Sonic the Hedgehog Extended Edition
    I "solved" the problem. I say "solved" with speech marks as it's kind've a cop-out method and I don't fully understand why, but it does work. :P

    In Floor_ChkTile in Hivebrain's 2005 disassembly, or FindNearestTile in the SVN/ReadySonic's disassembly, you have to change
    Code (Text):
    1. moveq   #-1,d1
    into
    Code (Text):
    1. moveq   #0,d1
    normally and then add the 256x256 chunk pointer value at the end to d1.

    Instead of this, I changed it to..
    Code (Text):
    1. moveq   #-1,d1
    2. sub.l   #$FF0000,d1
    .. essentially taking away the original pointer first. This, for some reason, makes it work fine and you can go above the ceiling level properly. Something with the bit set after the #-1 set, I'd assume.

    But, yeah. Bug fixin'~
     
  18. FraGag

    FraGag

    Tech Member
    Applying this solution didn't work for me, when following my guide (maybe it's because I'm still adding the address of the chunk mappings to d1 afterwards...). However, I figured out the problem: when chunk 00 is encountered, it ends up using the collision from the first tile in chunk 01, which is solid in Spring Yard. It only occurs if this branch is taken:
    Code (Text):
    1.         beq.s   @blanktile  ; branch if 0
    or in the 2005 disassembly:
    Code (Text):
    1.         beq.s   loc_14996
    The original code ends up putting $FFFFFF00 in a1 in that case. I don't even know if it's ever set to a nonzero value...

    I fixed the guide. And then I fixed it again when I realized there's the same bug with rendering the empty chunk (you can see the empty chunk in SYZ1 using debug mode by going below the level height). Anybody who followed that guide should apply these changes (diff for both edits).
     
  19. Cinossu

    Cinossu

    Administrator
    2,820
    8
    18
    London, UK
    Sonic the Hedgehog Extended Edition
    Hm.. well, I think our methods are a little different anyway, looking at your guide, as I use a pointer in RAM for all chunks, and use that in the FindNearestTile / Floor_ChkTile routines. Either way, bugs are being fixed. :P
     
  20. TorchicBlaziken

    TorchicBlaziken

    Member
    6
    0
    0
    The Sonic the Hedgehog Plus hack has the Insta-Shield in it. Maybe you can ask permission from the creators of that hack to use their Insta-Shield code.