I am appearing out from the shadows... with a question: What is the most simple way in S2 to loop a check for a player status? For example, if a character is jumping/rolling, etc. How would I be able to constantly check for that state? I want to get back into fiddling around with code, but it seems I lost a LOT of knowledge since I last did this. >.<
Hi all. I'm posting a message on here because I'm feeling a bit overwhelmed with hacking Sonic 1. There are so many elements to consider and I'm struggling to understand some of them. My initial thought was to download a disassembly as advised in some of the threads / tutorials on Sonic Retro because I understand that once you get a good understanding of ASM you can do a lot of things with your hack. I understand that with a disassembly absolutely everything in the base game is split into components that you can edit through a text editor (for your code) and other utilities such as tile editors allow you to edit art etc. I know there is a lot more to this though but that's my general understanding. I started following the tutorial on here for implementing the spin dash to try and learn how to add new features to the game and I was able to follow along until the point where I needed to change the art for the spin dash. This is where I got stuck. I have a bunch of questions about this process. Please don't think I'm against researching, but I think I need a push in the right direction because I'm sure many of you would understand that it's very easy to get stuck in a rabbit hole and you end up not finding the info you need. ROM hacking is a very technical process and my thoughts are that it's not easy for a complete beginner to start. - Which program is generally preferred for editing art these days? - Are there any guides / tutorials available on how to use recommended art editing software specific to Sonic? - Is there any documentation available that explains how we work with art in disassemblies (uncompressed art, sprite mappings, palettes etc.)? The impression I get from the software available to hack these games is that they've been made by people who know the ins and outs of ROM hacking and as someone who's a complete beginner I'm finding it difficult to get on board.
@KawashiSquirrel There are other options for sure, but it still seems as though most people use SonMapEd. Here's a guide that covers loading, saving, importing and exporting. You'll need to make sure you select the correct game format under "Settings", ie. Sonic 2 for exporting the spindash frames, and then Sonic 1 when you import them back in. You'll probably have to fix the palette before you import it. Use the Sonic 1 palette for the duration of the process. (Honestly, for this process, copy-pasting the binary data in a hex editor would be about as easy as an import/export, but whatever) Make a backup of your disassembly if you've made any changes, then have a play around, explore the menus. Make mistakes. Figure out how you made the mistakes and how to avoid them. If I can offer some more general advice: If you haven't already, try some bugfixing guides before you try something like adding a whole character feature. Character mods are super popular because of the wow factor, but they're pretty advanced for a starting point. Gaining a familiarity with how the disassembly is setup will make everything easier for you.
I highly recommend SonLVL for levels, Flex 2 for sprite mappings, SonPLN (part of SonLVL) for plane mappings. SonLVL also includes editors for the S1 and S3K Special Stages.
Ok, so my previous question, while unanswered, is no longer the issue. Seems for what I was doing, I forgot to create a flag check in a routine for objects the player can stand on. But this leads me to a new question. I know it's possible to check object RAM for objects, and I thought I was doing this correctly, but it seems I am mistaken. Code (Text): MoveThing_NoSpring: lea (Object_RAM+$400).w,a1 moveq #$6F,d1 MoveThing_ObjLoop: tst.b (a1) ; is there an object in this slot? beq MoveThing_ChkNext ; if not, check next object cmpi.b #$41,(a1) ; is it obj41 (spring)? We don't want the move to activate if you hit one of these. bne.s Sonic_ROF4_End ; if yes, branch bra MoveThing_part2 ; Branch to activate move MoveThing_ChkNext: lea next_object(a1),a1 ; look at next object ; a1=object dbf d1,MoveThing_ObjLoop ; loop Basically, I don't want what happens at MoveThing_Part2 if the player has hit a spring. Edit: One more question, when using for button checks, is there a way to only play sound effects once? What I have currently, loops the sound until the button is released or the action occurs.
So that code, as it is now, will check whether the first non-empty object is a spring, and if it is, it branches to MoveThing_part2, otherwise it branches to Sonic_ROF4_End. Nothing about that code will tell you whether the player has hit a spring, and in fact I don't think there is a way to tell when you have hit a spring except by adding code into the spring object itself.
Yeah, I came to such a conclusion, I modified the spring object by moving one line from the bottom of a sub routine, to the top. Seems to pretty much solve the problem. Edit: I was able to fix my sound issue, it was indeed tied to checking if a button was held. But as this was still something I needed, I ran an additional button check before the line that plays the sound that checks if the button was simply pressed, this resolved the issue and the sound effect no longer loops and attempts to murder ears.
Hello, more S3 ineptness again I'm afraid. These are more intricate. * Anyone know how to add a flag to Knuckles HPZ boss so he's harmful to touch? Apparently he isn't hurt just by spin attacking him. If you land on him normal from the top, you hit him unharmed. I tried adding a branch in the enemy collision coding for Obj_CutsceneKnuckles but it didn't seem to do anything. * Anyone know details about Competition Mode, specifically it's countdown at the beginning of each race? It apparently resets if you activate the control lock flag, I wanna find out why so.
http://info.sonicretro.org/SPG:Solid_Tiles Can someone help me understanding how the sensors work? It doesn't really go into that much detail of how it was coded, moreso how they generally work.
Well, I can’t really answer your first question, but I have done research on Sonic 1 RAM locations and object variables (99% sure it’s the same in Sonic 2). Anyway, so the game knows whether or not Sonic is airborne through bit 1 ($02) of object variable $22 (or obStatus in GitHub disassembly). Sonic’s jumping, rolling and rolljumping flags are also handled by the same object variable (as bit 2 ($04) for jumping/rolling and and bit 4 ($10) for rolljumping). The object variable $3C is also set when jumping. If you’re trying to edit Sonic 3, look in one of the links below. Here’s links to all Classic Sonic trilogy games RAM locations: http://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_(16-bit)/RAM_Editing https://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_2_(16-bit)/RAM_Editing https://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_3_&_Knuckles/RAM_Editing
Here's a possibly dumb question. While I know that the S2K Upper Memory chip in Sonic & Knuckles contains mostly only code and a few art and object layout replacement, with most other data sourced from the Sonic 2 ROM, what I can't say for certain is how the game deals with the various Sonic 2 revisions. Naturally like with the original game I would presume that there are offset lists for the data, where the data includes two different sets, one for Rev 0 and Rev 1. Is that correct? Are the revisions more similar than I imagined, with matching data offsets? Are there references to other revisions in the code?
Whew, it's been a while since I was last here. And over that time I've forgotten the little that I knew about ASM. Anyways, in Sonic 1 (git disasm), how would I disable the resetting of a shield between stages?
The resetting of the shield between stages is more of a default byproduct of clearing object RAM and mass clearing common variables, therefore, it's more of an "enabling" of a feature to keep the shield. Before I explain how to put the feature in, I'll explain how the shield generally works. --- --- --- --- --- --- --- --- --- --- --- --- When the shield is activated two main things happen: The object is loaded (done by moving the shield ID into a common reserved object slot, this'll be "id_ShieldItem" ($38) into "v_objspace+$180" ($FFFFD180)). A shield flag is set (done by moving $01 to "v_shield" ($FFFFFE2C)). The object itself is for display purposes only, it will move its position to match Sonic's position and will display/animate the shield graphics. The flag "v_shield" is responsible for the engine handling Sonic's vulnerability, as long as this variable is non-zero, Sonic will be harmed a different way. The shield is removed by doing only one thing: The shield flag is cleared (done by forcing "v_shield" ($FFFFFE2C) to $00). The shield object (Object 38) will automatically delete itself if it detects "v_shield" to be zero. The shield flag is cleared when Sonic is harmed, or when he enters the giant ring at the end of a Zone, when the level is reset for the next act/zone, the entire of object RAM is cleared, thus clearing the shield object anyway, and the shield flag is automatically cleared in a list of common variable clears later down the same routine. --- --- --- --- --- --- --- --- --- --- --- --- To enable Sonic to keep the shield, the first thing we'll need to do is stop the flag from being cleared when a level is started, inside "sonic.asm" locate the label "Level_SkipClr:" and you'll need to remove (or comment out) this line: Code (Text): move.b d0,(v_shield).w ; clear shield So now, when the level is reset by normal means, the shield flag remains enabled, however, the objects itself for displaying the shield was cleared so we may need to reload that, in place of the line removed above put this in: Code (Text): tst.b (v_shield).w ; is Sonic meant to have a shield? beq.s Level_NoShield ; if not, skip move.b #id_ShieldItem,(v_objspace+$180).w ; set to reload the shield object Level_NoShield: This will check to see if the shield flag is still enabled, and if it is, it will set the shield object to load again. Now there are a few anomalies to take care of; first of all, when you enter a special stage giant ring, the shield flag is cleared to cause the shield object to delete itself so it doesn't display in the air after Sonic has disappeared. The giant ring's flash object is responsible for this, so inside "_incObj/7C Ring Flash.asm" you will find at label "Flash_Collect:" the line: Code (Text): clr.b (v_shield).w ; remove shield Now, we still want the shield to disappear, but only visually as we want to keep the status of the shield on for the next act, so instead of clearing the flag, we'll swap the above line for below: Code (Text): clr.b (v_objspace+$180).w ; remove shield (object only) This will simply clear the object itself by setting the object ID "00" into the slot. The second anomaly is Sonic's death, if Sonic is able to die instantly by either a bottomless pit or being crushed whilst still having the shield, he will keep the shield. To prevent this inside "_incObj/sub ReactToItem.asm" (seriously, I hope you appreciate this for you have no fucking clue sir how long it took me to locate the subroutine, my suggestion to those working on the GIT, put a "; KillSonic:" next to the include directive in the main source, that way it can be found much more easily)... You'll find the label "KillSonic:", and right below this line: Code (Text): move.b #0,(v_invinc).w ; remove invincibility You will need to add: Code (Text): clr.b (v_shield).w ; remove shield I suspect this was accidentally missed out, but since the level initialisation routine clears it on reset, it was never noticed. But this will ensure the shield is removed if Sonic dies whilst holding a shield.
So I am trying to figure out what I am doing wrong when hand writing animation scripts for Sonic. If I am correct in understanding, using the end flag/byte $FD, the next byte that is set afterwards would be the next animation to be displayed after the first one finishes, right? Well, in attempting to to just that, my animation freezes on the last frame, rather than continuing to the next one, and I cannot figure out for the life of me, why. Code (Text): SonAni_Move1: dc.b 0,$E6,$EA,$E7,$EA,$E8,$EA,$E9,$EA dc.b $E6,$EA,$E7,$EA,$E8,$EA,$E9,$EA dc.b $D6,$D7,$D8,$D9,$DA,$DB,$DC,$DD,$DE,$DF dc.b $E0,$E1,$E2,$E3,$E4,$E5 dc.b $FD,$23 Which should flow right into Code (Text): SonAni_Move2: dc.b 0,$D6,$D7,$D8,$D9,$DA,$DB,$DC,$DD,$DE,$DF,$E0,$E1,$E2,$E3,$E4,$E5,$FF Why it isn't working, I am lost on, because I know in past projects, similar code has worked, like when I changed Spindash to function more like the one from Sonic CD Code (Text): SonAni_spindashcharge: dc.b 5,$3C,$40,$3D,$40,$3E,$40,$3F,$40,$FD,$28 SonAni_spindashcharge2: dc.b 0,$3C,$40,$3D,$40,$3E,$40,$3F,$40,$FF
Alright, so I was able to fix some of the issue by using end flag $FE, which checks the byte after it, and depending on what that byte is set to, it loops back to a specific frame and loops the animation from there. Code (Text): SonAni_Move1: dc.b 0,$E6,$EA,$E7,$EA,$E8,$EA,$E9,$EA dc.b $E6,$EA,$E7,$EA,$E8,$EA,$E9,$EA dc.b $D6,$D7,$D8,$D9,$DA,$DB,$DC,$DD,$DE,$DF dc.b $E0,$E1,$E2,$E3,$E4,$E5 dc.b $FE,10 So This leads to a new question. Is there a way to check for that loop specifically? For example, if the animation isn't in the looping phase, branch to end?
Anything that's on the start of a line, not indented, is a symbol name. Symbols can be labels that give a name to a place in the ROM, a constant which has a value assigned to it that cannot be changed, a variable whose value can change over time, or a macro definition. If you're getting a "symbol undefined" error when following a guide, that probably means you have a different version of the disassembly than the guide was written for, or you did something wrong.
Does anybody know why animations for Sonic using frames at or past $F0 do not work? As in, is there any special reason that you shouldn't just change the line at SAnim_Do2 from $F0 to $FD? Also, how hard would it be to split the super form frames from base Sonic's art and call from a new file? Where should one start if looking to do so?
