Sonic 3 Hacking

Discussion in 'Engineering & Reverse Engineering' started by KingofHarts, Feb 7, 2013.

  1. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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.
     
  2. Tiddles

    Tiddles

    Diamond Dust Tech Member
    471
    0
    0
    Leicester, England
    Get in an accident and wake up in 1973
    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.
     
  3. TheInvisibleSun

    TheInvisibleSun

    OVER THE TOP TECHNO-BLAST Member
    1,409
    0
    16
    Buffalo, NY, USA
    Sonic 1 Color Contrast
    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).
     
  4. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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:
    Code (ASM):
    1. SME_pwc2r_1F8:            
    2. dc.b 0, 4
    3.             dc.b $EC, 8, 0, 0, $FF, $F3
    4.             dc.b $F4, $E, 0, 3, $FF, $F3
    5.             dc.b $FC, 2, 0, $F, $FF, $EB
    6.             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.



    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.
     
  5. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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:
    Code (ASM):
    1.  
    2. Obj_Sonic2P:
    3.                 cmpa.w  #$B000,a0
    4.                 bne.s   loc_105F2
    5.                 lea     (Sonic_Knux_top_speed).w,a4
    6.                 lea     (Distance_from_screen_top).w,a5
    7.                 lea     (Dust).w,a6
    8.                 move.b  ($FFFFB082).w,d0
    9.                 cmp.b   $38(a0),d0
    10.                 bne.s   loc_105E6
    11.                 bchg    #3,4(a0)
    12.  
    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.

    Code (ASM):
    1.  
    2. Obj_Sonic2P:
    3.         cmpa.w  #Player_1,a0 ; is Player 1 controlling the character object?
    4.         bne.s   loc_105F2    ; if not, branch
    5.         lea (Sonic_Knux_top_speed).w,a4
    6.         lea (Distance_from_screen_top).w,a5
    7.         lea (Dust).w,a6
    8.         move.b  (Player_2+character_id).w,d0 ; check Player 2's character
    9.         cmp.b   character_id(a0),d0          ; is Player 2 playing as the same character as Player 1?
    10.         bne.s   loc_105E6                    ; if not, branch
    11.         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.

    Code (ASM):
    1.  
    2. Obj_Sonic2P:
    3.         cmpa.w  #Player_1,a0 ; is Player 1 controlling the character object?
    4.         bne.s   loc_105F2    ; if not, branch
    5.         lea (Sonic_Knux_top_speed).w,a4
    6.         lea (Distance_from_screen_top).w,a5
    7.         lea (Dust).w,a6
    8.         tst.w   (Player_2).w                ; Is Player 2 playing? ; KINGOFHARTS FIX
    9.         beq.s   loc_105E6                    ; if not, branch ; KINGOFHARTS FIX
    10.         move.b  (Player_2+character_id).w,d0 ; check Player 2's character
    11.         cmp.b   character_id(a0),d0          ; is Player 2 playing as the same character as Player 1?
    12.         bne.s   loc_105E6                    ; if not, branch
    13.         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.
     
  6. TimpZ

    TimpZ

    Pending Approvals
    20
    0
    0
    Sweden
    Speedrunning, learning ASM??
    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 :)
     
  7. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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.
     
  8. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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:
    Code (Text):
    1. OBJECT - Sonic

    Code (Text):
    1. OBJECT - Sonic (2P)
    Code (Text):
    1. OBJECT - Tails
    Code (Text):
    1. 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.
     
  9. TimpZ

    TimpZ

    Pending Approvals
    20
    0
    0
    Sweden
    Speedrunning, learning ASM??
    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 :).
     
  10. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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...
     
  11. TimpZ

    TimpZ

    Pending Approvals
    20
    0
    0
    Sweden
    Speedrunning, learning ASM??
    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.
     
  12. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    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.
     
  13. Tiddles

    Tiddles

    Diamond Dust Tech Member
    471
    0
    0
    Leicester, England
    Get in an accident and wake up in 1973
    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. :)
     
  14. MainMemory

    MainMemory

    Every day's the same old thing... Same place, diff Tech Member
    4,269
    0
    16
    SonLVL
    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:
    Code (ASM):
    1.     lea off_92A1C,a1
    2.     jmp (a1,d1.w)
     
  15. TimpZ

    TimpZ

    Pending Approvals
    20
    0
    0
    Sweden
    Speedrunning, learning ASM??
    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 :) .
     
  16. MainMemory

    MainMemory

    Every day's the same old thing... Same place, diff Tech Member
    4,269
    0
    16
    SonLVL
    If you look before it spams all those errors, you see the REAL problem:
    Code (Text):
    1. > > >sonic3k.asm(22395): error: symbol undefined
    2. > > > id_SonicBalance
    3. > > >           move.b  #id_SonicBalance,anim(a0)
    It's trying to use labels that don't exist.
    In the root folder I noticed two Anim files. I moved them to the folder they should be in in a normal disassembly, General/Sprites/Sonic, and it built just fine.
     
  17. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    You guys have been pointing that out... and lemme tell you. You all have no idea how many hours I spent like a dumbass trying to get that "bug" to work... But yea, I had to take a minute to find it again.

    I can take care of that part. Matter of fact, I've started work on establishing an offline form of the SCHG for you all, for the benefit of those who cannot access the internet, or if... God forbid, Retro is down... I like to practice writing in my document before placing my wiki changes onto the actual website... I still have a ways to go, but it would contain the SCHG information for each of the 3 MD games, as well as an addendum for the How-To Guide. As I'm going through, I'm combing through for errors and the like... Each game is separated into its own document as well, so it is not too cluttered. I don't have any kind of immediate time frame for finishing this, though I may release an early version with the initial SCHG itself as soon as I can.
     
  18. KingofHarts

    KingofHarts

    Member Member
    1,617
    0
    0
    Project Sonic 8x16
    An update. I isolated the monitor code, and... seeing as how there is code for the object in Sonic's 1 and 2 to copy off of, this was fairly easy. So here you go, just copy the code in this asm, and paste it into yours. I've tested, and it builds and runs fine. Lemme know of any mistakes and the like.

    It's not FULLY complete, but its labeled and all... so messing with Sonic 3's monitor code should be a little bit easier now.
     
  19. Tiddles

    Tiddles

    Diamond Dust Tech Member
    471
    0
    0
    Leicester, England
    Get in an accident and wake up in 1973
    TimpZ: sorry, somehow I missed your post about the slope glitch in the page change! I'm at work at the moment, but I've had a quick scan over the AIZ rocks and the ICZ blocks and the breaking code is quite different. I'll try to have a look in the near future to see if I can find an easy fix for the ICZ floating madness based on comparing them, or just looking at where the logic is falling over for the ICZ objects.

    EDIT: Yeah, I think I see how to fix this. Will try tonight and let you know.
     
  20. Tiddles

    Tiddles

    Diamond Dust Tech Member
    471
    0
    0
    Leicester, England
    Get in an accident and wake up in 1973
    OK, this will fix it for the ICZ ice blocks.

    Look for:

    Code (ASM):
    1. loc_8B3D2:
    2.         bset    #2,$2A(a1)
    3.         move.b  #$E,$1E(a1)
    4.         move.b  #7,$1F(a1)
    5.         move.b  #2,$20(a1)
    6.         move.w  #-$300,$1A(a1)
    7.         bset    #1,$2A(a1)
    8.         bclr    #3,$2A(a1)
    9.         move.b  #2,5(a1)
    10.         btst    #4,$2A(a0)
    11.         beq.s   loc_8B41A
    12.         lea (Player_2).w,a1
    13.         bset    #1,$2A(a1)
    14.         bclr    #3,$2A(a1)
    Now add some stuff in the middle so it looks like this:

    Code (ASM):
    1. loc_8B3D2:
    2.         bset    #2,$2A(a1)
    3.         move.b  #$E,$1E(a1)
    4.         move.b  #7,$1F(a1)
    5.         move.b  #2,$20(a1)
    6.         move.w  #-$300,$1A(a1)
    7.         bset    #1,$2A(a1)
    8.         bclr    #3,$2A(a1)
    9.         move.b  #2,5(a1)
    10.  
    11.         btst    #3,$2A(a0)              ;
    12.         beq.s   +                   ;
    13.         lea (Player_1).w,a1             ;
    14.         bset    #1,$2A(a1)              ;
    15.         bclr    #3,$2A(a1)              ;
    16. +                               ;
    17.  
    18.         btst    #4,$2A(a0)
    19.         beq.s   loc_8B41A
    20.         lea (Player_2).w,a1
    21.         bset    #1,$2A(a1)
    22.         bclr    #3,$2A(a1)
    I.e. add the section with the semicolon comment markers on the right. Adding comments is left as an exercise for the reader. (Because I'm lazy.)

    But in essence: this whole section is run when the ice block is destroyed, and a1 will have been loaded by the previous section with a pointer to the object RAM of the player who destroyed it. It clears any status of that player standing on an object and bounces them up a bit, amongst other things. Then the bit at the bottom, under where I added the fix, goes "Hey, by the way, was player 2 also standing on this object? Let's drop him off it if so." But it never makes any explicit check for whether player 1 is standing on the object, and as such it never drops him if player 2 broke the block.

    I suck at explaining this stuff, and that's one of many reasons you don't see any guides by me! But I hope that makes some sense and someone can translate it into something meaningful. If anyone wants to suggest some more objects where similar stuff occurs I can look into those too, but as ever, I make no promises as to when that may be.

    You will probably also have to look a few lines up and change a beq.s locret_8B430 to a beq.w. Such is life.