ReadySonic

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

 

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

 

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.

 

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.

 

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.

 

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?

 

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?

 

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.

 

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

 

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.

 

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

 

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.