What are we all using to edit music nowadays? I kinda want to take some MIDIs and put them in my hack, but I don't know how to do that :s. Midi2SMPS is cool I guess, but I don't really understand how to not make it sound like butt. And also I don't know how to transpose a MIDI to SMPS, by hand or otherwise. Help please? Thanks EDIT: also, in 4noob terms, how would one go about making a second Sonic with different stats (I guess taking the place of Tails) with different accelerations, speeds, etc (Maybe I'm adding Modern Sonic, maybe not What do I do in the ASM file?
Sorry. I guess it's my fault that mid2smps isn't very user-friendly. But it has improved a lot over the last year and I want to release an updated version sometime in May.
I take it you want to hack Sonic 2 correct? If so in your disassembly make a search for "Obj02_Init", this code contains Tails' stats. If you want to change his stats, change this code to whatever you'd wish: Code (ASM): move.w #$600,(Tails_top_speed).w ; set Tails' top speed move.w #$C,(Tails_acceleration).w ; set Tails' acceleration move.w #$80,(Tails_deceleration).w; set Tails' deceleration Hope this helps. Also if you wanted to change his Speed Shoes stats, just make a search for "super_shoes_Tails".
Hi another S3+K question, mainly concerning giving Sonic Tails' stipulations: 1. Is there any way to get Sonic's ending animations to load in a similar manner to Tails (eg. for emerald endings, the super transformation and pallette load but then still play the normal ending animation afterwards)? 2. Is there anyway to have Sonic's levels start up like Tails' (eg. skip the Angel Island and Ice Cap intros)? I've tried editing the character flags related to the intros but all it does is glitch things up. 2. Out of curiosity, is that black and white death sprite used for anything in game? I'm really scraping for spare sprite spaces here.
Random question, how would I get Sonic to slow down when a button (in my particular experiments, the B button) is not being pressed/held? Resetting the speed (like after the speed shoes wear off) doesn't work seemingly, as you still carry on going the same speed until you slow down yourself. The desirable thing would be an immediately visible slowdown...this is for a boost code I'm trying out for my Sonic 1 hack (Hivebrain disassembly, if past questions didn't give it away XD).
It's been ages since I modified anything in a Sonic game, but wasn't the speed stored in RAM address $FFF604? Something like that, anyway. If I remember correctly, this is the value that just about every routine that deals with the speed writes to or read sfrom, so you'd want to go ahead and just write the new speed there. (Original cap was $600 IIRC?)
It is yes, but when I tell it to use that speed when I release the button, it decides to walk on it's own (even with no input) at that speed based on what way I'm facing when I let go...sometimes backwards oddly enough.
Are you wanting to program in Sonic Boost? If so, it's not too difficult. What I did was made a check to see if the B button was held, and if it was it branched to another part of my routine that handled his boost speed. And if the B button wasn't being pressed, he'd run at normal speed.
Well I've had a little help to get what I have so far, so I'm gonna PM you the code I have as that would probably make more sense than simply going by description XD
I'm pretty darn sure that sprite isn't used for anything, at least. As for the other questions: definitely possible, but I couldn't say exactly how from a quick skim. I suspect both require editing specific character checks - possibly more than one each - within the code rather than being anything that can be fixed with a quick tweak to a table or static data. I'm afraid I won't have time to check it through myself for the moment, but I'll have to look at the Icecap startup sooner or later, so if I see anything useful I'll let you know.
Cool. Thanx for that. Oh I just figured out how to edit the Icecap one myself so if you need help with that I can assist. It is indeed editing a couple of character checks, one regarding start locations (loc_1BEC6) and another regarding graphics (loc_690A). I managed to get to a mid point with Angel Island's startup, mostly editing checks labelled over it's intro, it loads the same way as Tails now, however the levels' pallette and graphics are screwed up and as you progress a flurry of garble sprites rises and kills Sonic.
Cheers for the Icecap tips. Now I think about it, I do know something about the AIZ intro, because I did pretty much the reverse of what you're doing to create an intro for Tails. My copy is all monkeyed about from the various intro changes, but these are places you definitely want to change. There may be a few I didn't spot here - like an idiot, I didn't comment them all the same way as each other, so some may have slipped through the net. Code (Text): LoadLevelLoadBlock: move.w (Current_zone_and_act).w,d0 bne.s loc_782A cmpi.w #2,(Player_mode).w bcc.s loc_7826 tst.b (Last_star_post_hit).w beq.s loc_782A You always want to follow that bcc path - so you should actually just remove everything from cmpi.w down to the beq.s at the end of that block. (You could always just change bcc.s to bra.s to test it first and leave a safety net to go back to.) Code (Text): loc_1BE7A: lea (a1,d0.w),a1 moveq #0,d1 move.w (a1)+,d1 move.w d1,($FFFFB010).w moveq #0,d0 move.w (a1),d0 move.w d0,($FFFFB014).w tst.b (Last_star_post_hit).w bne.w loc_1BF74 cmpi.w #0,(Current_zone_and_act).w bne.s loc_1BEC6 cmpi.w #2,(Player_mode).w bcc.s loc_1BEC6 move.w #$40,d1 ; If in Angel Island Zone and playing as Sonic, the start position is overridden for the intro move.w d1,($FFFFB010).w move.w #$420,d0 move.w d0,($FFFFB014).w move.w #0,d1 move.w d1,(Camera_min_X_pos).w move.w d1,(Camera_target_min_X_pos).w move.w d1,(Camera_min_X_pos_P2).w Again, you want to always follow that bcc after cmpi.w #2, and the solution is pretty much the same again - clear the stuff in between or bra.s it. (If you remove it all, you will also have to remove the previous cmpi.w/bne too in this case, as it would become a zero-length branch.) Code (Text): LoadLevelLoadBlock2: move.w (Current_zone_and_act).w,d0 bne.s loc_1C2C8 cmpi.w #2,(Player_mode).w bcc.s loc_1C2C4 tst.b (Last_star_post_hit).w beq.s loc_1C2C8 You know what to do. Code (Text): loc_1C46E: move.b #1,($FFFFF72E).w cmpi.w #$1000,(Camera_X_pos).w bcs.s locret_1C4CE move.b #0,($FFFFF72E).w move.w (Camera_X_pos).w,(Camera_min_X_pos).w cmpi.w #$1308,(Camera_X_pos).w bcs.s locret_1C4CE tst.b (Last_star_post_hit).w bne.s loc_1C4A6 cmpi.w #2,(Player_mode).w bcc.s loc_1C4A6 moveq #$B,d0 jsr (Load_PLC).l Honestly, I didn't remember that these were all the same answer at various well hidden locations. I was hoping I could say something cleverer. Oh, this is another one that might result in a zero length branch if you're not careful. Code (Text): loc_1C4D0: move.w #$1308,(Camera_min_X_pos).w cmpi.w #$1400,(Camera_X_pos).w bcs.s locret_1C54E tst.b (Last_star_post_hit).w bne.s loc_1C522 cmpi.w #2,(Player_mode).w bcc.s loc_1C522 lea (AIZ1_16x16_MainLevel_Kos).l,a1 lea ($FFFF9268).w,a2 jsr (Queue_Kos).l lea (AIZ1_8x8_MainLevel_KosM).l,a1 move.w #$17C0,d2 jsr (Queue_Kos_Module).l st ($FFFFEEC6).w move.w #$500,($FFFFF7F0).w move.w #$500,($FFFFF7F2).w move.w #$500,($FFFFF7F4).w Same old business, more short branches to watch. Code (Text): loc_6248: move.w d0,(Level_music).w bsr.w Play_Sound tst.w (Current_zone_and_act).w bne.s loc_6268 cmpi.w #2,(Player_mode).w bcc.s loc_62B6 tst.b (Last_star_post_hit).w beq.w loc_62FE bra.s loc_62B6 Ditto. Clearly I started the search from the middle, as we've wrapped around. Too lazy to rewrite it now! Code (Text): SpawnLevelMainSprites: move.l #Obj_Level_6C2C,(Reserved_object_3).w bsr.w SpawnLevelMainSprites_SpawnPlayers bsr.w SpawnLevelMainSprites_SpawnPowerup tst.b (Last_star_post_hit).w bne.w locret_69B6 tst.b (Special_bonus_entry_flag).w bne.w locret_69B6 lea (Player_1).w,a1 lea (Player_2).w,a2 cmpi.w #0,(Current_zone_and_act).w bne.s loc_6834 cmpi.w #2,(Player_mode).w bcc.s locret_6832 move.l #Obj_84,($FFFFB172).w clr.b (Level_started_flag).w No short branch concerns this time. Have a sticker!
In the Sonic 1 Hivebrain disassembly, is there a way to check if Sonic is in midair? Like if sonic is in midair, do this etc. I ask this because with the boost I'm using, rings drain on the ground but not in the air annoyingly.
Thanx, Tiddles. There was one more section I had to uncomment for graphics a little after loc_1BE7A, but it was pretty easy to find. Does the coding for draining rings have a bsr in the MdJump sections as well as MdNormal? That's the best I can think of right now.
No problem. Surprised I was of any use. Two more S3+K queries: 1. Does anyone know where the coding for Hyper Sonic's object destroying white flash is? I want to activate it with other buttons and flags. 2. Just asking about the ending query again. Even if someone knows where the routine is to load the ending animations so I can try myself would be appreciated. The ending routine is a friggin' maze. Sorry for littering this thread as of recently. Hopefully these are the final two bugs before I'm done.
loc_11A96 looks like the boy for hyper dash - well, that's the move in general, I'm not sure what part of it does the flash without looking more closely. Let me know if that's not enough to get you going. The ending stuff, I dunno, that's what I was having trouble trying to find for you. As you say, it's a mess - there are so many character checks for various things in the ending, and the code for it sprawls quite a long way out. I think you should be looking from somewhere around loc_5E2C2. The first subq/bpl here, I believe, is checking the credits countdown; once that bpl check fails, it starts running ending pose stuff. My fix for Tails' tails being missing during his jump at the end fits in here too (clr.l (Tails_tails).w was a bit of a clue for that one!)
Right, more boost code problems XD I have some code for it to basically branch to an rts (so that it doesn't boost/drain rings) when ducking, rolling, or standing still (as it raises acceleration rather than forces a forward motion). Problem is, this same code won't work for pushing. It works fine and stops the drain when standing/waiting/rolling/ducking, but for some odd reason still drains rings when pushing. Here are the branches I used: Code (Text): cmpi.b #8,$1C(a0) ; is Sonic ducking? beq.w endofboost ; if yes, branch cmpi.b #4,$1C(a0) ; is Sonic pushing? beq.w endofboost ; if yes, branch cmpi.b #5,$1C(a0) ; is Sonic waiting? beq.w endofboost ; if yes, branch cmpi.b #2,$1C(a0) ; is Sonic rolling? beq.w endofboost ; if yes, branch As you can see the format is exactly the same for each, which leaves me rather perplexed...I've tried adding it at the start of the drain section too just in-case, but that also didn't work. Maybe some sort of check to not drain rings if not moving could work but I'm not entirely sure. Any thoughts?
(This is talk from Sonic 2, so if your hack isn't Sonic 2, this might not work) The problem here, is if you actually look at Sonic's animation RAM address and see it change for all his animations, when Sonic goes into his pushing animation, nothing is moved there. Look at it when pushing, I bet you 4 isn't there. This is the same for when he is walking/running. I had this problem in my burst code for my hack. So instead, for when Sonic is walking, I made it move #1 to a new RAM address called "sonicwalking". For when he is running, I made it move #2 to the address. And for when pushing, move #3 to the address. #0 for none of them. Code (ASM): lea (SonAni_Walk).l,a1 ; if yes, branch move.b #1,(sonicwalking).w ; move 1 to address (for Sonic's burst) Code (ASM): lea (SonAni_Run).l,a1 ; use running animation move.b #2,(sonicwalking).w ; move 2 to address (for Sonic's burst) Code (ASM): lea (SonAni_Push).l,a1 move.b #3,(sonicwalking).w ; move 3 to address (for Sonic's burst) Code (ASM): Obj01_MdJump: clr.b (sonicwalking).w This is from my hack, so then in my burst coding, I can do this: Code (ASM): maybekillburst: ; does a couple of checks before killing the burst just in case cmpi.b #5,anim(a0) ; is sonic standing? beq.s killburst ; immediately kill burst if so cmpi.b #3,(sonicwalking).w ; is sonic pushing? beq.s killburst ; immediately kill burst if so cmpi.b #1,(sonicwalking).w ; is Sonic walking? beq.s maybekillburst ; maybe kill burst if so This is the only solution I could think of at that time, and can't be arsed to think of another right now, so try this. Works perfectly fine for me, and it doesn't slow things down =P EDIT: Just use a RAM address that is not used. You might want to clear the RAM address in more places rather than just when Sonic jumps, but for my burst coding, just when Sonic jumps is good for me.
Not quite sure how that would translate into Sonic 1's disassembly but I'll investigate it. Hmm...any idea how I could say test if sonic's speed is 0? If I can do that, then in theory I could set it to not drain rings if his speed is 0...which would be while he's pushing