Basic Questions and Answers Thread

Hey that's mean! You're under the impression he knows he has to plug in the toaster first!

 

Thats right! Sorry for the confusion!

 

can you PM me on how to port it?

 

No. I am personally not even involved in disasm hacking anymore. Plenty more things to spend time working on than another unremarkable example of why the game engine should be completely eviscerated and rewritten from scratch. Find your hacking help from someone who actually uses the disaster known as BOOM.

 

Just watched your video, war 1 or 2. What level slot is EHZ in? You list it last in your list. Does it come after SBZ / Final Zone by any chance? Your problems start part of the way into SBZ Act 1 and continue throughout the rest of the level.

When this happened to me, it generally meant that I put in more data / less data than what there was previously and all the pointers beyond that point got messed up. Of course, when I was porting levels, I was doing it in Hex and not 68k asm.

In asm, I'm guessing you probably didn't move the art or collision over correctly. Sonic 1 is kind of a pain to work with as far as hacking goes, though. I'd recommend Sonic 2 or even the Simon Wai S2Beta. I have a soft spot for the beta and the level layouts aren't Kosinski compressed which is nice. Sonic 2 is by far the easiest to work with, though.

I also found it was easiest to get my art and collision from a savestate to start with and then write a C++ app to Nemesis compress it using the outlined algorithm on Sonic Retro. The savestate has it all lined up neatly for you to just grab and separate. It works beautifully.

EDIT: Just saw this...

No one needs to tell you how to do something. If you want to learn how to do anything, you have a computer and the Internet. I recommend looking for your information by searching these forums or looking on the wealth of knowledge on the Sonic Retro wiki. You can find it by going to http://info.sonicretro.org/. None of us have the time to hold your hand.

 

Just a 3 quick questions for Sonic 1 Git disasm:

1. S3K horizontal springs allow the player to rebound off them in the air, unlike the previous Sonic games. How could I make Sonic 1 horizontal springs act the same?
   
   Changes to the stock $41 Spring object shown below.
   Problem is rebounding in the air sometimes work, and when it does, the spring keeps rebounding after hitting (and still pushes Sonic even when he is on the ground using spooky-action-at-a-distance)
   
   
   Code:

   Spring_LR:    ; Routine 8
           move.w    #$13,d1
           move.w    #$E,d2
           move.w    #$F,d3
           move.w    obX(a0),d4
           bsr.w    SolidObject
           cmpi.b    #2,obRoutine(a0)
           bne.s    loc_DC0C
           move.b    #8,obRoutine(a0)
   
   loc_DC0C:
           btst    #5,obStatus(a0)
           bne.s    Spring_BounceLR
          
           ;!@ Attempt hitting spring from air
           tst.b    obColProp(a0)    ;!@ has Sonic touched the    spring?
           bne.s    Spring_BounceLR
           rts   
   

2. How can I change the palette line used for some Sonic 1 objects' nemesis art? I've tried changing the palette line for some objects in SonMapED (by pressing "p") and saving the art again, but some objects seem to have their palette line defined and hard-coded elsewhere in the game. For example, I'm trying to force object $6C SBZ Vanishing platform to use palette line #0 (Sonic's palette) instead of #2 (FG art palette).
   
   
3. For the Sonic 1 Git disasm, two different addressing schemes are used for the Pattern Load Cues VRAM address and for the VRAM Setting for the Debug List for level objects ("_inc/Pattern Load Cues.asm" and "_inc/DebugList.asm" respectively). What is the equation to convert between the two addressing schemes?
   
   Sample object for Rings:
   
   
   Code:

   DebugList.asm:
   [*]@GHZ:
       dc.w (@GHZend-@GHZ-2)/8
   
   ;        mappings    object        subtype    frame    VRAM setting
       dbug     Map_Ring,    id_Rings,    0,    0,    $27B2
   
   
   Pattern Load Cues:
   
   PLC_Main:    dc.w ((PLC_Mainend-PLC_Main-2)/6)-1
           plcm    Nem_Lamp, $F400        ; lamppost
           plcm    Nem_Hud, $D940        ; HUD
           plcm    Nem_Lives, $FA80    ; lives    counter
           plcm    Nem_Ring, $F640     ; rings
           plcm    Nem_Points, $F2E0    ; points from enemy
       PLC_Mainend:
   

 

1: I remember doing an ugly hack for this back in the day. I may look into what the springs do differently sometime later
2: http://info.sonicretro.org/SCHG:Sonic_the_Hedgehog_(16-bit)/RAM_Editing#Object_Status_Table_Format
3: the VRAM setting in debug lists are the same as art tile (2 in obj ram), or what is described in the link I posted, while in PLC it is an absolute VRAM position; tile number multiplied by 0x20.

 

But where is Sonic_Walk? in my disassembly?

 

Can you not use the "Find" function on notepad (or whatever you're using to view your ASM) and then search for it?

 

Ain't i stupid! Oh, anyways, how DO i make a hack in general? (I have no idea what i'm doing)

 

If I were you, I would try reading either (or both) ASM guides:

My guide for beginners: http://info.sonicretro.org/SCHG_How-to:Work_with_Motorola_68000_assembly
MarkeyJester's guide for advanced beginners: http://mrjester.hapisan.com/04_MC68/

And then pick your favourite Sonic game out of Sonic 1, or Sonic 2, and pick a disassembly so you have it from fresh: http://info.sonicretro.org/Disassemblies


It's always good to edit a favourite Sonic game of yours so you stay motivated, but Sonic 1 and 2 are the easiest to handle.

This way, you can open up the ASM file, and start reading the guide. Once you learnt what each instruction does, you can then start looking at the ASM file and make small little changes, save it and then test it. And when I mean small changes, I mean like this (do this after a bit of reading).


Go to "super_shoes:" in the Sonic 2 disassembly and change this:

Code:

 move.w #$C00,(Sonic_top_speed).w

to this:

Code:

 move.w #$300,(Sonic_top_speed).w

Build and test. When you next get speedshoes in the game, you'll notice you've gone a lot slower. You can call them slow_shoes if you wish!

After a few months of reading and messing around, you'll get the hang of the ASM codes, know what each instruction means, and start to make sense of each paragraph of code. Then you'll be able to start a brand new hack of your own with another fresh disassembly. I hope this advice helps.

 

I would also recommend: https://www.youtube.com/user/animemaster222/playlists some are incomplete but I have video guides which can be easier to understand sometimes.

 

Thank you!

 

You're welcome, just one more thing though, and it's not related to hacking, but please do not quote the post directly above yours. Only quote a certain part or posts far up the page. Thanks

 

I'm seriously thinking of doing so,but will continue with Sonic 1 to fix any errors & attempt to turn it into something else.
one of these days I'll get it right.

 

I am sure

 

I'm currently in the process of porting the Burrobot from Sonic 1 to Sonic 2 and I got most of the stuff licked except for one thing: what should I replace "v_player," "v_vbla_byte" and "v_debuguse" (from Sonic 1's original code for the badnik) with from the library of Sonic 2 variables? The reason I'm asking this mainly is that I'm having some hard luck finding the right variables for them. Any help on this bit is appreciated.

 

v_player = MainCharacter;
v_vbla_byte = Vint_runcount+3;
v_debuguse = Debug_placement_mode.

EDIT: I approach this ocassion to ask, do any Sonic 1/2 styled spritesheet for Knuckles exist somewhere? I have searched a lot and I lost all hopes.

 

Thanks for solving the variables problem. Now I'm faced with a different problem:

Code:

> > >s2.asm(90591): error: addressing mode not allowed here
> > >         lea     (loc_1001FA), a1
> > >s2.asm(90606): error: addressing mode not allowed here
> > >         lea     (loc_1001FA), a1
> > >s2.asm(90751): error: jump distance too big
> > >         bsr.w    AnimateSprite
> > >s2.asm(90752): error: jump distance too big
> > >         bra.w    MarkObjGone

And part of the problem lies beneath this section of the Piranhabot code:

Code:

loc_1000BA:
        lea     (loc_1001FA), a1
        bsr     J_AnimateSprite_06      ; loc_1DE9E
        bsr     J_SpeedToPos_0B         ; loc_1DEA4
        tst.w   $3A(a0)
        bgt     J_MarkObjGone_14        ; loc_1DE98
        cmpi.w  #$FFFF, $3A(a0)
        beq     J_MarkObjGone_14        ; loc_1DE98
        move.l  #$FFFB8000, $36(a0)
        addq.b  #$2, $24(a0)
        move.w  #$FFFF, $3A(a0)
        move.b  #$2, $1C(a0)
        move.w  #$1, $3E(a0)
        bra     J_MarkObjGone_14        ; loc_1DE98
loc_1000FC:
        move.w  #$390,($FFFFF646).w
        lea     (loc_1001FA), a1
        bsr     J_AnimateSprite_06      ; loc_1DE9E
        move.w  $3E(a0), d0
        sub.w   d0, $30(a0)
        bsr     loc_1001AC
        tst.l   $36(a0)
        bpl.s   loc_100154
        move.w  $C(a0), d0
        cmp.w   ($FFFFF646).w,d0
        bgt     J_MarkObjGone_14        ; loc_1DE98
        move.b  #$3, $1C(a0)
        bclr    #$6, $22(a0)
        tst.b   $2A(a0)
        bne     J_MarkObjGone_14        ; loc_1DE98
        move.w  $10(a0), d0
        asl.w   #$1,d0
        move.w  d0, $10(a0)
        addq.w  #$1, $3E(a0)
        st      $2A(a0)
        bra     J_MarkObjGone_14        ; loc_1DE98

And the other part of the problem in a section of the Burrobow code:

Code:

Burro_Action:    ; Routine 2
        moveq    #0,d0
        move.b    routine_secondary(a0),d0
        move.w    index(pc,d0.w),d1
        jsr    index(pc,d1.w)
        lea    (Ani_Burro).l,a1
        bsr.w    AnimateSprite
        bra.w    MarkObjGone

Does anybody know what I did wrong in these code sections that lead to the problem?

 

'error: jump distance too big' means the code pointed to is too far away for a branch instruction to reach. You need to replace them with jumps (bsr->jsr, and bra->jmp). People ask about that error a lot, so you can find plenty of info if you search.

As for that 'addressing mode not allowed here' error, I think it might be because there isn't a '.l' after the label in brackets. You can see how it's meant to be in the line 'lea (Ani_Burro).l,a1'.