MarkeyJester's Sonic 128 - REVAMPED

RetroKoH · Aug 26, 2013

Y'all remember this? Of course you do. 3 years ago MarkeyJester brought this wonderful mod to us all. For those that use this... one complaint may have been that it is in the old Hivebrain disassembly, and NOT in the new updated disassembly. Now, that said, Markey DID label all of his changes with ;MJ: so a port shouldn't be too hard... and could easily be done by anyone of us with minimal effort... BUT given that nothing of the sort had happened... at least to my knowledge, I decided to take it upon myself to perform the task.

Now, for newer hackers that don't know how, or don't want to try to port this over... it is here. Also this should bring Markey's project back into the limelight because quite frankly I much prefer this to the original Sonic 1 method. There are a couple things to point out, however... FIRST is that I have ported NO bugfixes to this disassembly. It is only the latest Sonic 1 HG disassembly with MJ's 128 mod.

SECONDLY, there is the issue with switching the ROM from the REV00 to REVJP1 revisions. As of right now, there are some background issues... I'm looking into them.

Big thanks goes to Markey, of course. Without him, we would not have this at all to begin with. Now, hopefully more people can/will make use of it.

https://github.com/s...tSonic1TwoEight - It's now officially on the GitHub repository! Please disregard any other download links from this thread and get it there! Thank you Clownacy, MainMemory and any others who contributed to the new disasm.

MainMemory · Aug 26, 2013

Did you modify the SonED2 and SonLVL project files accordingly? I may start providing INIs for this with SonLVL's updater.

RetroKoH · Aug 27, 2013

I modded the SonLVL files, but didnt get around to SonED2. the SonLVL files may need work though, in particular with the path swapper definitions. Everything seems to display properly aside from that.

Caverns 4 · Aug 31, 2013

First off, I do want to say thank you for doing this, and I want to make it clear that I do appreciate you putting forth the effort, I just do have a few points of constructive criticism that I would like to see addressed. None if this is intended to point fingers or ridicule what you, or any other contributor has done, or say you're wrong, but simply a vent about something that bothers me.

One thing that's always bothered me about the newer disassembles that didn't really get fixed here, is the inconsistency.

I know that Sonic 1 and 2 are different games, have different routines, and different RAM setups, but what's so special about one or the other where every variable, even the ones that mean the same thing, have to be named differently?

For example, lets look at "LevSel_Ptrs:", which in Sonic 2 is "LevelSelect_Order:" (Which is easier to read by the way)

In this, the levels are labeled as id_GHZ, 0, id_GHZ, 1, etc, using dc.b

But in Sonic 2, it's literally a straightforward (albeit longer to type), emerald_hill_zone_act_1, emerald_hill_zone_act_2, etc, using dc.w

Sonic 2's it longer to write but easier to read.

Now, lets use a different example.

In Sonic 2, the RAM variable for the camera's y position is simply "camera_y_pos".

In this, if I just open Sonic.asm and search even for "Camera", I get no results. What is the variable, if there even is one?

One more: Opening Sonic.asm and searching for Obj01: yields no results. in the old disassembly, it did have results. When you split the object data, the label got moved into the new file, and honestly, that just makes it a little harder to find going by popular labels.

Again, please forgive me if this came of as cynical, it was not meant to be such. I appreciate this contribution, and I'm sure it will be more useful than the older 1-28 disasembly once I know the ropes.

RetroKoH · Sep 1, 2013

Caverns 4 said:

Abbreviated: The non-matching nomenclature is a pain in the ass...
Click to expand...

Agreed. Honestly I've had the same complaint about the nomenclature for a while, and while I don't see it changing overall for the HG disassemblies, This is something I'd like to do something about sometime in the future as well... though it won't necessarily be in THIS project.

BTW I wanna take the time to say this, I'll be posting an update at some point (cannot promise when)... as there are some things that bug me. One of them include how the loops work... In this build, go ahead to any GHZ or SLZ loop and start to walk up one incline... and when I say START, I mean, just far enough that you're starting to go up an incline. Jump back a bit. BAM, you are now completely on the other side of the loop. Doesn't work like that in Sonic's 2 or 3. I'm hoping to fix this.

Caverns 4 · Sep 1, 2013

KingofHarts said:

Caverns 4 said:

Abbreviated: The non-matching nomenclature is a pain in the ass...
Click to expand...

Agreed. Honestly I've had the same complaint about the nomenclature for a while, and while I don't see it changing overall for the HG disassemblies, This is something I'd like to do something about sometime in the future as well... though it won't necessarily be in THIS project.
Click to expand...

I'm glad you agree with me. If you're interested in formulating some consistency with them, I'll be willing to help.

BTW I wanna take the time to say this, I'll be posting an update at some point (cannot promise when)... as there are some things that bug me. One of them include how the loops work... In this build, go ahead to any GHZ or SLZ loop and start to walk up one incline... and when I say START, I mean, just far enough that you're starting to go up an incline. Jump back a bit. BAM, you are now completely on the other side of the loop. Doesn't work like that in Sonic's 2 or 3. I'm hoping to fix this.
Click to expand...

From what it sounds like, the path swappers simply don't have their ground flag set. If I'm not mistaken anyway.

Hang on.. I see something wrong. Why are all the pathswappers object $10? There were 3 before... Similarly, they appear properly in SonLvL in the older disassembly I have of 1-28. Did you shift Object ID's around?

RetroKoH · Sep 2, 2013

I did shift them to Object 10. I was going to originally do this only for REV C, but I ended up doing it for this as well on accident... and just got too lazy to switch it back. My reasoning for switching them had to do with wanting to use the Objects 02-07...
I can confirm that it isn't causing any bugs... at least none that I know of. If it's a bother to anyone though... I'll switch them back. I can understand if it throws people off... what with porting layouts and all. It'll be a little while before I update it though. I've got a couple of other projects at the forefront ATM.

Secondly about the labeling and nomenclature... I'd love to collaborate with you on this. I've also started Sonic 3K... though I kinda neglected it lately. We could start on Sonic 1 and 2 getting squared away and work from there. Which nomenclature would you prefer? Because I prefer Sonic 2's... it's more clear IMO and also S2 and S3 match up well together so it's a little less work on that end.

Caverns 4 · Sep 2, 2013

KingofHarts said:

I did shift them to Object 10. I was going to originally do this only for REV C, but I ended up doing it for this as well on accident... and just got too lazy to switch it back. My reasoning for switching them had to do with wanting to use the Objects 02-07...
I can confirm that it isn't causing any bugs... at least none that I know of. If it's a bother to anyone though... I'll switch them back. I can understand if it throws people off... what with porting layouts and all. It'll be a little while before I update it though. I've got a couple of other projects at the forefront ATM.

Secondly about the labeling and nomenclature... I'd love to collaborate with you on this. I've also started Sonic 3K... though I kinda neglected it lately. We could start on Sonic 1 and 2 getting squared away and work from there. Which nomenclature would you prefer? Because I prefer Sonic 2's... it's more clear IMO and also S2 and S3 match up well together so it's a little less work on that end.
Click to expand...

1: Shifting Object IDs around and such, in my opinion, should be left up to the hacker. That said, the same rules for a normal dissassembly about being as accurate as possible to the original don't apply necessarily here, so unless something changes, I leave it in your hands. Personally though, I would prefer it be on 03 for consistency.

2:I'm glad you like the idea. In further agreement, I also prefer Sonic 2's nomenclature, for it's ease to understand. It's definitely the system I would go with if I were to do it myself (Which in fact, I sort-of have done with the Nick Arcade Prototype disasembly so as to make porting stuff easier).

RetroKoH · Oct 13, 2013

Here's an update (DOWNLOAD NOT AVAILABLE, PLEASE SEE OP). I've made the following changes:

* I've started on fixing the path swapper bug mentioned earlier in the thread... haven't gotten it fully fixed yet... as it still occurs on the SLZ loops, but it should no longer occur on the GHZ loops anymore.
* I've shifted the Path Swapper back to Object 03.
* Path Swapper object definition works and appears properly in SonLVL
* The newer SonED 2 project files all work properly with Sonic 1-Two Eight HG
* I've removed the OLD SonED 2 project files. I haven't been able to get them working no matter what I tried. If they are requested, I'll re-add them as is and let someone else give it a go... otherwise there's no need to have them.

I'll update this with more if need be...

RetroKoH · Aug 26, 2014

Reviving this topic with an update (DOWNLOAD NOT AVAILABLE, PLEASE SEE OP). IDK why it took me so long to do this but there should be no more issues with the path swappers at all.

After looking through Sonic 2's level layouts, I now have a better understanding of how the path swappers should be used. Now they should work properly in all areas.

Please let me know if more things need to be fixed...

MainMemory · Aug 26, 2014

I don't know if you're aware of this, but it was put on GitHub as a branch of the S1 disassembly a while ago.

Clownacy · Aug 26, 2014

*facepalm* I knew there was someone other than MarkeyJester I had to notify of this.

Alright, for the record, since the readme.md isn't going to be of any help: The Git version had the path swappers fixed (ground-only flag, right?), and the path swappers were given some debug functions from the Wai Beta (turn on debug mode, the path swappers appear as rings and, when passed through, play the checkpoint sound), some code was optimised, and S2's OOZ sliding chunk detection replaced MJ's own version. The good ending was fixed, and the waterfall splash object's LZ3 wall check was fixed. SonLVL and SonED2 (non-v1.0x) compatible.

The Git version was built from the ground up using the original Hivebrain source and a clean master-branch Git disasm, so don't get the wrong idea from MainMemory's "it was put on GitHub".

More here.

RetroKoH · Aug 26, 2014

Oh wow! I had no idea. Well then, I'll go check it out! And for good measure I'll link the GitHub version at the top of the topic.

MarkeyJester · Aug 26, 2014

Oh wow guys, congratulations on fishing out the last bugs! The missing water object I just totally missed!! Donno how I did that... =%

Either way, it's great to see the system as solid as it is.

RetroKoH · Sep 1, 2014

Code (Text):

ObjHitWallLeft:

add.w x_pos(a0),d3

move.w y_pos(a0),d2

lea (v_anglebuffer).w,a4

move.b #0,(a4)

movea.w #-$10,a3

move.w #$400,d6 ; MJ 128 EDIT

moveq #$D,d5 ; MJ: set solid type to check < MARKED LINE

bsr.w FindWall ; MJ: check solidity

move.b (v_anglebuffer).w,d3

btst #0,d3

beq.s locret_15098

move.b #$40,d3

Unless I missed it, you guys missed deleting this line in the latest revision.

Clownacy · Sep 1, 2014

Just 'guy', I was the only one involved in that change. It seems that in Sonic 2, there are some hardcoded areas like that. Unless you accounted for those and had found an exception.

RetroKoH · Sep 1, 2014

So... that part should stay as is then?

Clownacy · Sep 2, 2014

Yeah. The entire point of that commit was to make the system more S2-like. So, no bugfixes or the sort. Those would be made into a guide here that could applied to both S1-28 and S2.

What you're looking at shouldn't be a bug. You see, ObjHitWallLeft is most likely for non-player use only, and since the layer system doesn't apply to non-player objects, the additional checks aren't needed. What that code there is doing is checking the left/right collision bits(?) of the primary (default, no loop) collision.

RetroKoH · Sep 2, 2014

Clownacy said:

Yeah. The entire point of that commit was to make the system more S2-like. So, no bugfixes or the sort. Those would be made into a guide here that could applied to both S1-28 and S2.

What you're looking at shouldn't be a bug. You see, ObjHitWallLeft is most likely for non-player use only, and since the layer system doesn't apply to non-player objects, the additional checks aren't needed. What that code there is doing is checking the left/right collision bits(?) of the primary (default, no loop) collision.
Click to expand...

Good to know. I will double check the commit difference to my source and make sure they match up then. Thanks for that!

flamewing · Sep 2, 2014

Clownacy said:

What that code there is doing is checking the left/right collision bits(?) of the primary (default, no loop) collision.
Click to expand...

Left/right/bottom collision bits of the primary collision, yes.

MarkeyJester's Sonic 128 - REVAMPED

Useful Searches