[KingofHarts]

OK. Purpose: This forum topic is to offer up any kind of insight, bug-fix or design change guides, etc. to the table, that we may use in the future. Much similar to THIS topic for Sonic 1 and THIS topic for Sonic 2.
I would like to use the creation of this topic in an attempt to promote and encourage working with and hacking Sonic the Hedgehog 3 & Knuckles (F___ You, it's Sonic 3). If we take a look at the Sonic Retro scene... the only people I have seen hacking Sonic 3 are mostly Tech Members... the most notable hack off the top of my head being Sonic 3 Complete, as well as Hayate's hack. We need more of this from S3.

On top of this topic, I am currently going through the Sonic 3K disassembly currently available on our Mercurial repository, and relabeling and commenting everything I can find, so that it is not as much of a nightmare to deal with. It's going to take time... but I'll post a .zip of a better labeled disassembly here when done. I hope that in the future, this can be placed in the repository in place of the currently unlabeled one, for ease of new users.

I will also place any and all fixes, changes, etc. into the SCHG How-To's section, much like I did last year for many of the fixes found for Sonic's 1 and 2, that came from RHS, Esrael, and many others who really kicked all sorts of ass with that stuff. Not every little fix or change will go in though, as I think the How-To's should be more of any and all important/difficult fixes, as well as any necessary and/or useful tutorials for making changes... like THIS and NOT quite like THIS... The second example is a nice idea... but if we post EVERY little nice idea possible into the SCHG, and not just guides on HOW to put nice ideas into the game... it really clutters up the SCHG, and kinda defeats the purpose of it, does it not?

Now, unfortunately I don't have much else to really kick us off... I haven't gotten to work on any changes myself to the game... Only thing I've done is changed Knuckles' mappings on his looking up sprite so that he doesn't shift forward... but that's WAY TOO EASY, and not necessary to explain how to do.

[Tiddles]

I don't know, isn't it? It's (most likely) a bug. and as much as the fix is as trivial as changing a couple of bytes, it tells you some things like where Knuckles' mapping file is, where his looking up frames are, and if you're not familiar with the format, a little about how it works. It's being able to pick up something mind-numbingly simple that can often lead you on to trying other things, particularly if you've been warned off touching S3K at all because of what a bogeyman it's supposed to be to work with.

As far as the relabelling goes, does this mean you're looking through the labels with loc_xxxxx type names and figuring out what they do to give them a sensible name? Would be interesting to see a sample section with some better labels and comments! This sort of thing tends to be extremely helpful, natch.

[TheInvisibleSun]

Tiddles, on 07 February 2013 - 01:37 AM, said:

As far as the relabelling goes, does this mean you're looking through the labels with loc_xxxxx type names and figuring out what they do to give them a sensible name? Would be interesting to see a sample section with some better labels and comments! This sort of thing tends to be extremely helpful, natch.

This. It certainly helped me to understand a lot about how to work with Sonic 1 (which still has some areas that are still unnamed/unconverted by the way, namely Final Zone and it's relevant functions and routines, for example).

This post has been edited by TheInvisibleSun: 07 February 2013 - 03:26 AM

[KingofHarts]

Good sir, good point. Ok then, TUTORIAL TIME! First off then, if you haven't already done so... please go pick up the following: A Sonic & Knuckles Split Disassembly, and SonMapEd. NOW if you don't know how to use SonMapEd, I suggest you take a quick look at THIS, and THIS, before proceeding. I'll still walk you through how to do everything though, so don't worry. It is REALLY EASY!

Right then. Take a look at your disassembly. Now if you work with the Sonic 1/2 disassemblies, this will look... different. This is because the file layout is not based on WHAT the files are, rather... the context in which they are used. Personally I prefer the former... and will be organizing it that way in my Sonic 3 REV C disassembly when I work on that. ANYWAY, Open the "General" folder. This will contain mappings, palettes, art, etc. for all of the characters, enemies, etc. outside of the main 1P levels. (The zones can be found in the "Levels" folder below "General" for future reference.)

IMPORTANT: Before doing anything else, Go to "Settings > Game Format" in the SonMapEd menu. Select Sonic 3 & Knuckles. Be sure to change this each time you work with a different base game, as each games files are handled differently (Most notably mappings... and PLC's, I think though I could be wrong). Ok, proceed...
Now, we want Knuckles' mappings. They are found in "General" > "Sprites" > "Knuckles" > "Map - Knuckles.asm". Now, you can open it if you want, but in its unlabeled messy state, chances are, you may not know what to do with it. SO, let's have SonMapEd do it for us. Open SonMapEd, and... provided you read the SonMapEd tutorial I linked above... you know how to at least open the files. So go load Knuckles art (Load Uncompressed Art) (Knuckles > Art > Knuckles.bin), his palette (Load Primary/Full Palette) (Knuckles > Palettes > Main.bin) - OPTIONAL, BUT BETTER TO JUST DO THIS, his mappings (Knuckles > Map - Knuckles.bin) AND finally, the DPLC's (Knuckles > Knuckles pattern load cues.asm)

Notice the sprite counter at the very top of the window? This will tell you what number your sprite is. You can have it in decimal numbers, or hex like mine. I'll give you the numbers in both, for this tutorial. Press the [ and ] keys to scroll through the sprites, and go to sprite 213/251 (D5/FB) Now, to fix this error, we want to fix the positioning of the sprite. To shift the sprite up, down, left, or right, hold SHIFT and hit the respective arrow key. This will shift the sprite by 1 pixel. NOT holding shift with the arrow keys will shift the sprite 8 pixels. We don't need to do that here, since the sprite is only off-center by 1 pixel. So for this sprite, and the one directly after that, shift them over 1 pixel to the left. Now, go ahead and save the mappings file. Rename the old one "Map - Knuckles OLD", and don't overwrite it, as we are going to look at what we did.

Now build (Build Scripts > buildS3Complete.bat) and run, and voila. Fixed! Now, for education's sake... lets look at what we ACTUALLY did. Open up both of your Map - Knuckles.asm files and compare them with each other. They will be difficult to look through and compare, as SonMapEd's output is a bit different in appearance compared to the original disassembly file. Here is, generally speaking, what the mappings of the first file looks like:

SME_pwc2r_1F8:            
dc.b 0, 4
			dc.b $EC, 8, 0, 0, $FF, $F3
			dc.b $F4, $E, 0, 3, $FF, $F3
			dc.b $FC, 2, 0, $F, $FF, $EB
			dc.b $C, 4, 0, $12, 0, 3

This page explains what all of these numbers mean, and so will I. The first two numbers are the number of pieces (clusters of tiles put together) that make the sprite. In SonMapEd, press the ; or ' keys to scroll through sprite pieces. Afterwards, you have lines of hex that are in this format YY SS VV VV XX XX. I'll explain each one in detail.

• YY - (Y Position) The relative signed top edge position of the sprite from the center of the object. So look at the 1st byte of the 1st piece. $EC is -20. The top of the piece is 20 pixels above the center of the sprite.
• SS - (Shape/Size) is the size of the sprite, in tiles minus one. The upper four bits are ignored, the next two bits control the width and the lowest two bits control the height. Thus sprites can be of any size from 1x1 tile to 4x4 tiles. For example, $01 is a 1x2 sprite, $02 is a 1x3 sprite, $04 is a 2x1 sprite, and so on. NOW you know why we are using sprite PIECES! Anyway, the first piece here says 8, which is 1000 in binary. So that means it is 3x1 (bits 10 is 2, bits 00 is 0. Add #1 to both of these).
• VV - (VDP/V-Ram read/settings) This word will be added to the object's VRAM offset and then used as the pattern index for that sprite. Like all SEGA Genesis VDP pattern indices, it is a bitmask of the form PCCY XAAA AAAA AAAA. P is the priority flag, CC is the palette line to use, X and Y indicate that the sprite should be flipped horizontally and vertically respectively and AAA AAAA AAAA is the actual tile index, I.e. the VRAM offset of the pattern divided by $20. Both being at zero, that means that priority=false, it uses palette line 1, the tile is not flipped, and the piece starts with using the first tile.
• XX - (X Position) This is the relative signed left edge position of the sprite from the center of the object. So... just like with the YY byte, this is just converted to decimal. This time, though, it is 2 bytes. So what have we got? $FF F3. This is -13 in decimal. We now know that it is 13 pixels to the left of the center of the sprite. Using the XX and YY coordinates, we can locate the center of the sprite, BTW. Just thought I'd mention that.

Now, let's find out where we made a change. In the OLD file, search for:word_14BA3E:. In the new one, search for: SME_pwc2r_1168:. Not much more for me to say here. I think you get the idea.

TheInvisibleSun, on 07 February 2013 - 03:23 AM, said:

Tiddles, on 07 February 2013 - 01:37 AM, said:

As far as the relabelling goes, does this mean you're looking through the labels with loc_xxxxx type names and figuring out what they do to give them a sensible name? Would be interesting to see a sample section with some better labels and comments! This sort of thing tends to be extremely helpful, natch.

This. It certainly helped me to understand a lot about how to work with Sonic 1 (which still has some areas that are still unnamed/unconverted by the way, namely Final Zone and it's relevant functions and routines, for example).

That is EXACTLY what I am doing. Also making comments, and will give the variables and whatnot the same name as what my Sonic 1/2 disassemblies have. It'll be difficult and time consuming though...


EDIT: I'm working (albeit at a very slow, holiday speed) on cooking up a sample with Sonic 3's Sonic object code... Learned something, I did. Sonic and 2P Sonic are different objects, as we all know... but they actually share much of the same routines! Only the init and control routines are different... Hmm... I'll post the asm for Sonic when its ready. It'll come in its own smaller asm file that you can copy/paste into your Sonic 3 disassembly's asm.

This post has been edited by KingofHarts: 10 February 2013 - 03:03 AM

[KingofHarts]

I'm back with an update. Unfortunately it is NOT YET an .asm release... I got a little bit of work to do. Some small errors I made, mainly in commenting, though a couple of other things as well.

However, I do have another fix, another small graphical fix, this time related to Competition Mode. When playing Competition Mode, you'll notice that you may play as the same character if you desire. What happens is that your character will appear flashing in the other player's window, and vice versa. Now, if you are playing a 1 Player only game, the character doesn't need to flash, and therefore doesn't... UNLESS of course, you are playing as Sonic. Sonic, unlike Tails and Knuckles, will always flash on the second screen by himself. If you play with Sonic against Tails or Knuckles, he WON'T flash... but will always flash when he's alone. Why is this of course? Well let's take a look.

Open sonic3k.asm and search for the following label: "Obj_Sonic2P:" You will see this code:

Obj_Sonic2P:
                cmpa.w  #$B000,a0
                bne.s   loc_105F2
                lea     (Sonic_Knux_top_speed).w,a4
                lea     (Distance_from_screen_top).w,a5
                lea     (Dust).w,a6
                move.b  ($FFFFB082).w,d0
                cmp.b   $38(a0),d0
                bne.s   loc_105E6
                bchg    #3,4(a0)

This is the code, as it appears in the current revision of the Sonic and Knuckles disassembly. For your benefit, please replace it with this relabeled block below, straight from Sonic 3 REV C (And part of the sample I will give to you all.)
don't WORRY ABOUT THE RELABELS. THEY EXIST IN THE CONSTANTS ASM AND THERE WILL BE NO ERRORS.

Obj_Sonic2P:
		cmpa.w	#Player_1,a0 ; is Player 1 controlling the character object?
		bne.s	loc_105F2    ; if not, branch
		lea	(Sonic_Knux_top_speed).w,a4
		lea	(Distance_from_screen_top).w,a5
		lea	(Dust).w,a6
        move.b	(Player_2+character_id).w,d0 ; check Player 2's character
		cmp.b	character_id(a0),d0          ; is Player 2 playing as the same character as Player 1?
        bne.s	loc_105E6                    ; if not, branch
		bchg	#3,render_flags(a0)          ; This allows the character to flash on the other screen?

Ah... that's better. So, as we can see, when in Competition Mode, The Player 1 object's character id is compared to the Player 2 object's character id, and if they match, the character will flash below on Player 2's screen. Now that's fine... but let's think about this: character_id works like this: #0 - Sonic, #1 - Tails, and #2 - Knuckles. SO... if there is no Player 2 object, then the RAM address for Player 2's character_id ($FFFFB082) will be $00, along with much of everything else associated with Player 2. THIS is what causes Sonic to flash below when he really doesn't need to, while Tails or Knuckles wouldn't do so. NOW, this can be argued that its not really a bug... but I'm calling it as such... as really just an oversight, and I have a VERY EASY FIX. See below. AGAIN, YOU CAN COPY THIS DIRECTLY INTO YOUR CODE, THE LABELS EXIST ALREADY IN THE CONSTANTS ASM FILE, AND THERE WILL BE NO ERRORS.

Obj_Sonic2P:
		cmpa.w	#Player_1,a0 ; is Player 1 controlling the character object?
		bne.s	loc_105F2    ; if not, branch
		lea	(Sonic_Knux_top_speed).w,a4
		lea	(Distance_from_screen_top).w,a5
		lea	(Dust).w,a6
		tst.w   (Player_2).w             	; Is Player 2 playing? ; KINGOFHARTS FIX
		beq.s   loc_105E6                    ; if not, branch ; KINGOFHARTS FIX
        move.b	(Player_2+character_id).w,d0 ; check Player 2's character
		cmp.b	character_id(a0),d0          ; is Player 2 playing as the same character as Player 1?
		bne.s	loc_105E6                    ; if not, branch
		bchg	#3,render_flags(a0)          ; This allows the character to flash on the other screen?

As you can see, the character_id comparison branches ahead to prevent the character flashing. What I did, was add a word test to check the Player 2 object RAM address. If Player 2 is playing, this word will appear as 0001. If not, it will appear as 0000. This occurs regardless of character. So, its simple. If the word is 0000, the game will branch ahead, completely skipping the character_id comparison, as it is redundant due to lack of a second player. AND VOILA! Sonic will now appear solid below, when racing alone. Oversight/bug/oddity fixed!

I'll keep posting more, and will have a much larger sample available for you all. I really hope that the efforts can help promote MORE SONIC 3 HACKING. Also much thanks to Tiddles, who has been kind enough to go out of his way to assist me with this project.
EDIT: Fixed the code comments. Please excuse the bad spacing. The asm tags on Retro's forum aren't the easiest things to work with... and I'm not redoing this.

This post has been edited by KingofHarts: 17 February 2013 - 07:26 PM

[TimpZ]

If you take requests for tutorials, anything that would help me getting started with editing level boundaries, boss spawns, killzones, water, vertical wrapping, level transitions, changes during gameplay etc. would be much appreciated.

I currently am planning a couple level designs (on paper) and I really want to use the S3K engine if I were to implement them because of it's superiority compared to the others, but not being proficient in hex-editing or ASM is very offputting.

Also, great work, this is very useful

This post has been edited by TimpZ: 22 March 2013 - 09:12 AM

[KingofHarts]

Aside from Tech Members providing such things, it will be a little while before I can do the same.
I still really need to sit down and get back to work on this. I apologize, I've kinda dropped the ball on this lately, with work on Triad taking the forefront, and having been just sick as a dog this past week.

I'm hoping that in due time, as I can get more work done on the ASM, we will have more available for less experienced S3K users to work with. Please bear with me.

[KingofHarts]

WOW that took WAY TOO LONG. I apologize... I am back with THIS. It is simply a rough start... but will hopefully illustrate a little bit of what I am doing. The following .asm's have been edited:
sonic3k.asm < Main asm file with all of the objects and stuff. This was obviously the biggest change. I have relabeled a lot of variables and subroutines to more closely match that of Sonic's 1 & 2... with most of the work having been done to Sonic's code. You can now begin searching for objects by running a search for:

OBJECT - Sonic

OBJECT - Sonic (2P)

OBJECT - Tails

OBJECT - Knuckles

sonic3k.constants.asm < Added some constants for character id's, Player modes, and zone/act ids. Also made a couple of other changes with regards to labeling some RAM addresses used by Tails/Player 2.
General\Sprites\Sonic < Check the animation .asm files as I've begun labeling these as well. I'm doing these in the style of the Sonic 1 HG disassembly. If they should be done in the style of Sonic 2's, or just differently altogether, lemme know.

Please take the time to test these and make sure that all is well, and also give some feedback. Tiddles gave me a great deal of assistance towards starting this as well, so a big thank you to him (and many more in the future, I'm sure). Which reminds me.... Thanks to Tiddles, I've been able to ensure that Sonic 3 REV C uses the newest HG disassembly version.

The only other change was to Knuckles' mappings, as noted in the bugfix guide I posted earlier in this thread. There is STILL a shitload that needs to be done but I wanted to make clear that this IS getting started on, and I've delayed showing a sample for FAR too long. Again I apologize. I'm also going to do some browsing and posting some bugfixes from RHS last year into this thread as well, as he and others gave us a few good fixes that applied to both Sonic's 2 and 3K.

[TimpZ]

I must say this is some awesome work. The relabeling makes it much easier to follow for me. However, I wasn't able to compile the codes even unedited. I was under the impression that I could just replace the asm files in Stealth's S3K assembly but I got about 200 thousand errors so I'm guessing there might be a typo or something early in?

Also if we're discussing bugfixes here and not just posting fixes to them I got some stuff to ask about regarding slope glitch which I'm currently looking to find a good fix for.

I also added lots of glitches to that page myself so if there's a glitch that takes your interest among them but you don't know anything about it then just ask me .

This post has been edited by TimpZ: 01 May 2013 - 03:39 PM

[KingofHarts]

Are you sure there is no error on your end? Try with a fresh HG S3K disassembly, and insert the 4 files in my zip, replacing the 4 respective files in the disassembly. I've tested it multiple times, including once more just now. I'm getting 0 errors. Also I'll check out your list.

I've found, and downloaded a collection of videos from YouTube that have many of these bugs and oversights highlighted. The user can be found here.
Also, I've wondered about THIS bug...

This post has been edited by KingofHarts: 01 May 2013 - 08:32 PM

[TimpZ]

Well I downloaded this assembly and just copy pasted your asm files directly into the folder. After running the BuildS3Complete.bat I get this type of error:

"sonic3k.asm(206915): error: addressing mode not allowed here
jmp off_92A1C(pc,d1.w)"

ORKAL is a good source for glitches, even if many glitches are repeats of the same glitch but in different stages.

Honestly that looks more like a cheat or something. That "boss" usually has 96 hits ($B19B) so if not he must have corrupted that number or something else triggering its death. It's very hard to say without having his inputs unfortunately.

The list isn't finished, but it's a good start at least. There are many places where a specific thing works simply because of the layout, but generally you can check out speedruns or TASes. For example if you want the inputs for this video they are available here and then you can play it back using gens and watch the RAM for a more in-depth look.

[KingofHarts]

Hmm... I have no earthly idea what could be causing that. I also use the same disassembly... I did encounter the same type of error a few times upon building... though it was usually caused by a completely different thing. I have tried one more time on a new downloaded disassembly, and still have no issue. Perhaps we can ask Tiddles for some insight... I don't know what would be causing this.

[Tiddles]

TimpZ: does your downloaded Hg disasm work before you paste the new files in? I just tried putting together a fresh copy with KingofHarts's updates and it builds OK for me.

Could you maybe zip up your whole disasm folder and post it up? Maybe I can figure out what the difference is when I get a chance.

KingofHarts: I was looking for that AIZ "bug" video the other day actually! Thanks for finding it again. I'm pretty sure what happens there requires hacking, or intervention from GG or PAR codes.

On the subject of bugs: I am happy to discuss the things I know or have worked on for Sonic 3 Complete; I have never touched the slope glitch specifically, but I would think the best way to fix it would be to correct the objects that leave this bit set incorrectly in edge cases. I'm definitely interested in working with people to fix more stuff up, and on tutorialising anything I already have that falls into a bugfix category - there are just never enough hours in the day.

To that end, I'm thinking of allowing read-only S3C source code access to a limited group in the future for the purpose of documenting, sharing and discussing core fixes, and maybe folding some other findings back in, with the understanding that this does not constitute a licence to use anything other than bugfixes and specifically agreed material in outside projects - which is why it would have be a very limited group. I'm not promising it, I'm just considering it. And it really doesn't help with the slope glitch at this point anyway - but there's a lot of stuff that I think is sharable and useful and it'd be nice to find a way to do so without having to be a documentation hermit myself.

[MainMemory]

TimpZ, on 02 May 2013 - 12:13 AM, said:

"sonic3k.asm(206915): error: addressing mode not allowed here
jmp off_92A1C(pc,d1.w)"

AS is kind of dumb about these errors. What it should be telling you is that the label off_92A1C is too far away from that instruction for 8-bit PC-relative addressing (data has to be within 127 bytes of the instruction). I think later 68k revisions allow for larger PC-relative addresses, so it thinks you're trying to use that.

To fix it, you could either move off_92A1C closer to the jmp instruction, or do something like:

	lea off_92A1C,a1
	jmp (a1,d1.w)

[TimpZ]

The assembly works fine before replacing the files. Here's a link to the folder which is just a fresh download with the ASM files replaced.

You might be right, every other error states that the adressing mode isn't allowed on 68k. But if that means I have to edit the document then I don't know what to do because I get thousands of those errors.

Tiddles, as far as I understand slope glitch, it's just a value that tells the game if Sonic is on an object or not (among other things) and therefore if he should be standing or falling. Standing on an object and having it destroyed by something, for example Tails regarding the IC ice blocks freezes the value and the game regards you as on an object until you interact with another object from above or simply reload the stage (I'm guessing they kinda knew about it and therefore had Tails not able to e.g. break ring boxes because of that, but then simply forgot about the ice blocks? Who knows). It then consequently stores the inclination of the last slope in some other adress and regards the "object" you're standing on as having that angle. You get inside a wall and normal ejection routines take over. Now the thing I find weird is how you can jump around, get hit by enemies from the side etc. without changing the value, like it normally does when you're on an object and jump off. So I imagine finding the general process(es) that handles the value regarding objects and then adding code to compensate for the instance where the objects is broken without direct intervention from the player or something along that line would work.

The reason I bring it up though is because I'm not proficient enough with the ASM to find the correct place in the code to read off and to understand the process precisely, but I find it an interesting glitch that's present in a lot of the levels so it's definitely a key thing to adress regarding bug fixes.

EDIT: Actually I just realised that the rocks in AI doesn't trigger the glitch, so a good place to start is probably comparing the code between the ice and rocks .

This post has been edited by TimpZ: 02 May 2013 - 10:26 PM