oh I see. Uhm...I think it's a good idea to have the jumpdash, since right now she can't attack badniks either Eggman, cuz the jump makes her vulnerable so I'll give it a try at that code. Still, I wanna have a tailspin/kick attack and I'll be very done with the hack untill we figure out a walljump.
Okay first, to make an animation invulnerable against an enemy, go to Touch_Enemy and look for this coding: Code (ASM): Touch_Enemy: ; XREF: Touch_ChkValue tst.b ($FFFFFE2D).w ; is Sonic invincible? bne.s loc_1AF40 ; if yes, branch cmpi.b #2,$1C(a0) ; is Sonic rolling? bne.w Touch_ChkHurt ; if not, branch Now add the desired animation branch in between, like so: Code (ASM): Touch_Enemy: ; XREF: Touch_ChkValue tst.b ($FFFFFE2D).w ; is Sonic invincible? bne.s loc_1AF40 ; if yes, branch cmpi.b #$XX,$1C(a0) ; is Sonic using XX animation? beq.w loc_1AF40 ; if yes, branch cmpi.b #2,$1C(a0) ; is Sonic rolling? bne.w Touch_ChkHurt ; if not, branch Similar alterations are made to the monitor code above like so: Code (ASM): Touch_Monitor: tst.w $12(a0) ; is Sonic moving upwards? bpl.s loc_1AF1E ; if not, branch move.w $C(a0),d0 subi.w #$10,d0 cmp.w $C(a1),d0 bcs.s locret_1AF2E neg.w $12(a0) ; reverse Sonic's y-motion move.w #-$180,$12(a1) tst.b $25(a1) bne.s locret_1AF2E addq.b #4,$25(a1) ; advance the monitor's routine counter rts ; =========================================================================== loc_1AF1E: cmpi.b #2,$1C(a0) ; is Sonic rolling/jumping? bne.s locret_1AF2E neg.w $12(a0) ; reverse Sonic's y-motion addq.b #2,$24(a1) ; advance the monitor's routine counter locret_1AF2E: rts Into this: Code (ASM): Touch_Monitor: cmp.b #$XX,$1C(a0) ;"is Sonic using XX animation?" beq.s break_monitor ; yes tst.w $12(a0) ; is Sonic moving upwards? bpl.s loc_1AF1E ; if not, branch move.w $C(a0),d0 subi.w #$10,d0 cmp.w $C(a1),d0 bcs.s locret_1AF2E neg.w $12(a0) ; reverse Sonic's y-motion move.w #-$180,$12(a1) tst.b $25(a1) bne.s locret_1AF2E addq.b #4,$25(a1) ; advance the monitor's routine counter rts rts ; =========================================================================== loc_1AF1E: cmpi.b #2,$1C(a0) ; is Sonic rolling/jumping? bne.s locret_1AF2E neg.w $12(a0) ; reverse Sonic's y-motion break_monitor: addq.b #2,$24(a1) ; advance the monitor's routine counter locret_1AF2E: rts You will also need to make edits to the Final Zone boss coding as it has problems recognising alt attack animations Look for loc_19F50: Code (ASM): loc_19F50: addq.w #7,($FFFFF636).w cmpi.b #2,($FFFFD01C).w bne.s loc_19F48 move.w #$300,d0 btst #0,$22(a0) bne.s loc_19F6A neg.w d0 Now make branches to recognise you animation as well: Code (ASM): loc_19F50: addq.w #7,($FFFFF636).w cmpi.b #$XX,($FFFFD01C).w ; Is Sonic using XX animation beq.s Hit_FinalZone cmpi.b #2,($FFFFD01C).w beq.s Hit_FinalZone bne.s loc_19F48 Hit_FinalZone: move.w #$300,d0 btst #0,$22(a0) bne.s loc_19F6A neg.w d0 The ground attack animation is a bit big so I'll let you work on this rather large amount of coding first.
thanks! I'll let you know once I'm done with it. I'm gonna try adding the Jumpdash first then I'll get into that. Uhm btw...that code you just gave me what is it suppossed for? It does has to do with the custom attack or can I just apply it? because I don't have the sprites ready yet so I don't know which number are them yet
Oh well, it is mainly to program your animation to hurt enemies and boxes, so it's not much use until you have the animation ready.
thought so. Once I have my animation done I'll send a PM to you, since I don't want to spam this thread with convos xD
So, I got a little question, I feel kinda ashamed off, but whatever: How would I totally disallow a RAM address from being increased? Like, I have $FFFFFF90, which $500 at the beginning. This address is being in- or decreased, irregular. However, I just want the value to be decreased, it may not be increased at any time. How would I do that?
There's no way to lock a RAM address as far as I'm aware - the best you can do is put a check in V-int. Can't you just remove the code which is increasing that address and not implement any such code yourself?
I was reading the Sonic 2 disassembly (2007 xenowhirl) and finally starting to understand some points. I read up to the part about screen locking (camera locking) and it mentions for boss fights. Which got me thinking does locking the screen lock the level boundaries temporarily for the purpose, the way I interpret it is that it might lock the x co-ordinates because it wouldn't want you to leave the screen via left or right but would it lock the y co-ordinates. The reason I ask is because I remember debug mode on Wing Fortress zone and when the boss fight starts I debugged out of the boss 'room' and tried to jump down the gap, result = death. So are the level boundaries temporarily shrunk to the scope of the camera while the camera locks ... and is there a way to keep the camera semi-locked but extent the boundary and have the camera make slight movements ? (like the final boss of Sonic 2 GG/MS) This might be a completely stupid and easily explainable point but I'm only just starting to scratch the surface of ASM ... so be kind :P
Okay that helped with one bit. I can now at least get the characters normal sprites to appear in super ending, however when the plane pans further away, the sprite doesn't disappear and it still loads the close up super sprite albeit with the tiles garbled (my guess is because it recognises to load the normal tiles but still loads the super object mappings). I managed to work around the other query about editing the ending sprites art though, so that's one thing off the list. :D
So, I've got a problem. I'm porting over the Sonic 3 sprites over to my new Sonic 2 project, (original, aren't I? :v. All goes smoothly with the art and palette, but when I put the mappings in, the Z80 stops at the title card (I can tell as the DAC is practically nonexistant at this point). I think it has to do with a limit on the number of sprites, and if so, how would I get around this?
Perhaps someone can help me again with a small issue I've encountered while doing my hack. I used Selbi's Jumpdash guide that was found on http://sonicresearch.org/forums/index.php?...amp;hl=jumpdash but I have a small problem with it, sometimes it does kill enemies while sometimes doesn't and I get hurt. And I was wondering, is it something that I did wrong or is it a known issue of the guide? Thanks in advance and sorry if this is a dumb question or was already resolved
Did you follow the entire guide? If so, look back at your code and compare it to Selbi's. You may have left some important code out. I'm not sure if it's the code itself, because I haven't actually tested it myself, but looking at the forum people said that it does work...
Just a small question. Is it possible to put another game's pallet into something like Sonic 2? Like Ristar's pallet, using hacking utilities?
While you can just copy the raw palette over into the other game, you have to be aware of potential format differences. Palette colors aren't always mapped to the same pixels in all tile sets, so you would have to remap the colors to get the effect you want; there is a hacking tool for that but I forget its name. The second thing is that you have to watch out for the size of the palette; each tile can use one of four 16-color lines of the palette, so some games reserve different amounts of these colors and on different lines. I think Ristar and Sonic 2 use the same mapping so it should be ok; in most other cases you might have to use the remapping tool as before. Hope that makes sense.
Small question—how does the 2007 disassembly handle Sonic/Tails' palette after super revert? The SVN disassembly has a SonicandTails2.bin, but I can't seem to find out where the reverted character palette is being kept, nor how to separate it...
I was wondering if its possible to add water to any level in sonic2. And if so how would I add water to EHZ?