Heh, flattered you put one of mine in the 'of course' pile. Okay, questions: *I'm trying to get a control lock onto this Sonic 2 move, my guess is it would involve activating the 'move_lock' flag somewhere in the routine though I'm not sure where (also not sure if I can implement it while keeping the automatic nudge forward): Code (ASM): ; --------------------------------------------------------------------------- ; Subroutine allowing Sonic to attack ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| Sonic_Hammer: cmp.b #$23,anim(a0) bne.s lol7 move.w $14(a0),d0 move.w d0,d1 asr.w #3,d1 sub.w d1,d0 move.w d0,$14(a0) rts lol7: btst #1,(Ctrl_1_Held_Logical).w ; is Down button pressed? bne.s JmpTo_SonicHammerreturn ; if yes, return btst #6,(Ctrl_1_Press_Logical).w ; is A button pressed? beq lol ; if not branch move.b #$23,anim(a0) ; show hammer animation jmp Hammer_Cont JmpTo_SonicHammerreturn: jmp Sonic_Hammer_return Hammer_Cont: move.w $14(a0),d0 btst #0,$22(a0) beq lol8 neg.w d0 lol8: cmp.w #$400,d0 bgt lol move.w #$400,d0 btst #0,$22(a0) beq lol9 neg.w d0 lol9: move.w d0,$14(a0) lol: move.w $10(a0),d0 tst.w d0 bpl label neg.w d0 label: cmpi.w #$600,d0 bgt Sonic_Hammer_Return btst #6,(Ctrl_1_Press_Logical).w ; is A button pressed? beq.b Sonic_Hammer_return ; if not, return move.b #$23,anim(a0) ; show animation $23 move.w #$3D+$80,d0 ; play sound jsr (PlaySound).l Sonic_Hammer_return: rts ; End of function Sonic_Hammer Oh and if anyone knows how to work this, is there an equivelent flag for move_lock in Sonic 1? * How exactly do you switch pallettes for a sprite (eg. swap it from using Sonic's pallette to say Green Hill's). I also noticed some sprites use different pallettes for certain tiles, is that possible to implement? This would be useful for both Sonic 1 or 2.
To lock controls you will need to do: move.b #01,(Control_Locked).w iirc. Move_lock is for something completely different. (If you want it to lock controls and press something else, you'd need to run your code before sonic's move code, or else nothing will happen to hold your new buttons in place, PM me for more info. As for the palette line for certain objects, it's with the art tile, it's a question I asked a page or two back
You know the Walk-Jump bug in Sonic 1? It actually plays havoc with more than just the jump - it could just as accurately be called the Walk-Drown bug. A while ago, I extended the SCHG How-to:Fix the Walk-Jump Bug in Sonic 1 to cover the drowning issue, too. However, I've noticed that it causes problems with the normal death animation (in Rev 00) and with the Spindash when you port it, as well. It would be nice to have a fix that doesn't involve just querying for each of these states. The How-to says this: Does anyone know specificically what these "little animation bugs" are? I've tested it after simply removing that one line, and nothing seems to be amiss. Are there any examples of what actually goes awry when that line is removed?
What format are the 16x16 tiles in Sonic 1 & Sonic 2? Trying to get S1's 16x16s to load in S2 as an experiment.
I have a music ethics question that has been bothering me, so much that I stopped doing my original music idea. The original idea for the music in my hack was to be like Sonic rush, and sample hit old songs. However, I want to know if it is right or not to use FREE midis people made on FREE midi sites to check how the notes go. If not I will just go another direction, which is the safer "rip the best songs from genesis and SNES games." My friend said it was fine, however it is important to know how YOU guys feel about it. I just can't tell.
Sampling is a legal practice. Lots of bands do it, such as Daft Punk and every rap group ever. However... I would like to see what it would sound like if you sampled SNES and Genesis music and mixed them Sonic Rush style.
The flag sorta works. It does the correct motion and keeps the player from changing it, however it also disables other sequences that use the flag (eg. the Wing Fortress cutscene which you now have to create 'manually'). Also the flag only seems to clear when on the floor, similar to the jump dash flag, meaning if you swirve off a ledge it keeps falling in that direction with no control until you land. Here's how I implemented it if that helps: Code (ASM): Sonic_Hammer: cmp.b #$23,anim(a0) bne.s lol7 move.b #01,(Control_Locked).w move.w $14(a0),d0 move.w d0,d1 asr.w #3,d1 sub.w d1,d0 move.w d0,$14(a0) rts lol7: btst #1,(Ctrl_1_Held_Logical).w ; is Down button pressed? bne.s JmpTo_SonicHammerreturn ; if yes, return btst #6,(Ctrl_1_Press_Logical).w ; is A button pressed? beq lol ; if not branch move.b #$23,anim(a0) ; show hammer animation jmp Hammer_Cont JmpTo_SonicHammerreturn: jmp Sonic_Hammer_return Hammer_Cont: move.w $14(a0),d0 btst #0,$22(a0) beq lol8 neg.w d0 lol8: cmp.w #$400,d0 bgt lol move.w #$400,d0 btst #0,$22(a0) beq lol9 neg.w d0 lol9: move.w d0,$14(a0) lol: move.w $10(a0),d0 tst.w d0 bpl label neg.w d0 label: cmpi.w #$600,d0 bgt Sonic_Hammer_Return btst #6,(Ctrl_1_Press_Logical).w ; is A button pressed? beq.b Sonic_Hammer_return ; if not, return move.b #$23,anim(a0) ; show animation $20 move.w #$3D+$80,d0 ; play sound jsr (PlaySound).l Sonic_Hammer_return: clr.w (Control_Locked).w rts ; End of function Sonic_Hammer *Hmm, not quite sure how this pallette thing works even after looking at the recent discussion. Is it a Hex editor thing? *Oh some other things that have perked up if anyone knows, I've tried implementing the spring motion so it activates when you are next to it without jumping on top of it (like in Advance for Amy), I managed to get it to run only with the necessary animation, however I hear the spring activate and then the game freezes, anyone know what I've done wrong here?: Code (ASM): loc_18980: move.w #$1B,d1 move.w #8,d2 move.w #$10,d3 move.w x_pos(a0),d4 lea (MainCharacter).w,a1 ; a1=character moveq #3,d6 movem.l d1-d4,-(sp) bsr.w loc_1978E btst #3,status(a0) beq.s Obj41_Hammer bsr.s loc_189CA Obj41_Hammer: tst.b $25(a0) ; is Sonic on top of the spring? bne.s loc_189CA ; if yes, branch cmpi.b #$23,(MainCharacter+anim).w ; is hammer attack being performed? bne.s loc_189A8 ; if not, branch moveq #0,d0 ; clear d0 move.w $8(a0),d0 ; load block's X-pos to d0 sub.w (MainCharacter+$8).w,d0 ; substract Amy's X-pos from it bpl.s Obj41_XPositive ; if answer is positive, branch neg.w d0 ; otherwise negate d0 Obj41_XPositive: cmpi.w #45,d0 ; is Amy within 45 pixels of the spring (X-axis)? bge.s loc_189A8 ; if not, branch moveq #0,d0 ; clear d0 move.w $C(a0),d0 ; load springs's Y-pos to d0 sub.w (MainCharacter+$C).w,d0 ; substract Amy's Y-pos from it bpl.s Obj41_YPositive ; if answer is positive, branch neg.w d0 ; otherwise negate d0 Obj41_YPositive: cmpi.w #45,d0 ; is Amy within 45 pixels of the spring (Y-axis)? bge.s loc_189A8 ; if not, branch bra.s loc_189CA ; otherwise make spring bouncing rts loc_189A8: movem.l (sp)+,d1-d4 lea (Sidekick).w,a1 ; a1=character moveq #4,d6 bsr.w loc_1978E btst #4,status(a0) beq.s loc_189C0 bsr.s loc_189CA loc_189C0: lea (off_18FE2).l,a1 bra.w AnimateSprite rts ; =========================================================================== loc_189CA: move.w #$100,anim(a0) addq.w #8,y_pos(a1) ... * Oh and some of 1P's new sprites are overlapping onto Tails' (eg. tiles of 1p appearing on Tails when large sprites are used). Is there anyway to expand one of the characters' memory so they aren't merging into each other?
Here is the result of a few hours then. Yes it is short, because it isn't finished. I'll finish it later if you guys like it, or I will finish it later anyways.
I have a port of different art into LZ, and I want a different layout. The issue is that the old doors that slide to the left and right that are activated by a button are still there. How would I get rid of them for Act 1 only, or move them?
Random question...was messing around with object and such, and now Sonic shoots a fireball (the ones in MZ) by pressing A, and I've made it not hurt sonic upon launching it...how would I go about making the fireball able to hit monitors and badniks?
You need to make checks in TouchResponse for an object other than Sonic (in this case, the fireball) and call that routine from the fireball object, also set it so it only gets called after sonic launched it (setting a flag could help). There aren't many checks you have to do for the fireball though, there's an area which checks collision with rings which has to be changed to only apply to sonic. Also, porting status_secondary from sonic 2 helps a lot too. Call touchresponse and make the fireball invincible.
Well I decided to give things a go and by simply adding a jsr TouchResponse to the end of Obj14_Action, it destroys badniks and monitors...sometimes. Not sure how to explain it...just sometimes it does, sometimes it doesn't. I asked Psy and he said it might be something about the fireball's X & Y positions...but I can't find any checks for it. Any ideas what I should look for?
Code (ASM): move #$2700,sr Another line I see quite often, without knowing what it does. I'd also like to know why it doesn't need anything like .b, .w or .l.
Im not really sure, but I know markeyjester explained me something about hblank. Its used for loading different palettes for the 2nd half of the screen (like water). Ie, updating the horizontal pieces of the screen per frame. Vblank is actually loc_b10 in the june 2005 disassembly. Im not sure what it does though.
Code (ASM): move.w #$2700, sr That disables all IRQs, which includes the VBlank and HBlank interrupts. VBlank indicates when the frame has just finished being shown on screen (all graphics should be updated in this period when possible), while HBlank kicks in right after a scanline on screen ends (which is used to do mid-screen changes, aka raster effects). Er, that's really dirty and inaccurate, but I don't feel like explaining how the video hardware works =P The following code should reenable the interrupts, in case you're curious: Code (ASM): move.w #$2000, sr
I'll complement what Sik said. Selbi, read this: http://en.wikipedia.org/wiki/Cathode_ray_tube. It explains how a CRT works. I'll try to make this as simple as I can. Basically there is an electron beam that goes from left to right, doing one row per time. The time the electron gun takes to go back from right to left once a row is complete, is used as Hblank on the Genesis. The time the electron gun takes to go back from the bottom right corner to the upper left corner, is used as Vblank on the Genesis.
Hi E-122-Psi, I'll have a shot at answering this. The game is freezing because you put data onto the stack without taking it off again. The stack is used by the system to keep track of important things like where to go back to after an rts, and if you don't move data to and from it properly things go wrong very quickly! Here's what happens in the spring object: First, we put a bunch of data into d1, d2, d3 and d4. These will be used in the solidity routine, loc_1978E. Next, we copy these variables to the stack using this line: Code (ASM): movem.l d1-d4,-(sp) This is to keep them safe because we'll need them later. Now we run loc_1978E for Sonic, which messes around with d1-d4. Luckily we kept a copy. We now check to see if Sonic was standing on the spring, and do the bounce routine if he was (loc_189CA). Now, in the real game, we'd continue from loc_189A8. The first line is Code (ASM): movem.l (sp)+,d1-d4 This takes our data back off the stack again. It's now as it was before we started messing around with it, so the system finds its data where it expected it and everybody's happy. We now run the solidity routine again, this time for Tails. In your code it's possible to bypass the line that takes the data back off the stack. This can happen in two places: the branches to loc_189CA that you've added. It's easy to fix the second one by changing this: Code (ASM): Obj41_YPositive: cmpi.w #45,d0 ; is Amy within 45 pixels of the spring (Y-axis)? bge.s loc_189A8 ; if not, branch bra.s loc_189CA ; otherwise make spring bouncing rts loc_189A8: movem.l (sp)+,d1-d4 to this: Code (ASM): Obj41_YPositive: cmpi.w #45,d0 ; is Amy within 45 pixels of the spring (Y-axis)? bge.s loc_189A8 ; if not, branch bsr.s loc_189CA ; otherwise make spring bouncing loc_189A8: movem.l (sp)+,d1-d4 ;This line can now be reached. However, I'm slightly confused by the first one: Code (ASM): Obj41_Hammer: tst.b $25(a0) ; is Sonic on top of the spring? bne.s loc_189CA ; if yes, branch We've already checked to see if Sonic is standing on the spring by testing bit 3 of the spring's status (set in the solidity routine). The method you're using is the Sonic 1 version, which is now obsolete. I'm going to take a guess that you've copy/pasted this section of code from a Sonic 1 object. If that's the case, then just delete these two lines - job done.
I heard that if you try to fix the Walk-Jump in Sonic 1 with the Hivebran dissasembly and if you have ported the spindash using the tutorial, it might give some problems to it and won't work correctly. Can someone confirm me if this is true? I'd like very much to fix the walk-jump bug on my hack but since I have the spindash I'm not sure if it's going to mess it with it or not. Thx in advance!
