Basic Questions & Answers thread

I'll try that, right now the one im using is $F500

EDIT: $F400 doesn't work

 

Did you really put $F400 everywhere? In the Pattern Load Cues.asm as well as in the sonic1.asm? If yes, you will have to search a VRAM location yourself, for example using Gens KMod (CPU -> Debug -> Genesis -> VDP). Look for blank tiles, which are big enough so every single tile of the lamppost fits in.
Oh also, if you found a free spot, you can look in the Pattern Load Cues.asm and look up the location of the art which is before yours. For example, the points are at $F2E0. Each tile has a size of $20 (hence why the tile offset is divided by $20). So for each tile you have between your spot and the art before it, you add $20, if that makes any sense to you.

 

Phew, thanks. Got it to work. I'm using $F500 now and apparently it works fine both the points and the lamppost. Thank you!

 

That's easier said than done, at least from my end. I have been going down one by one which ones are which, for example:

Code (ASM):

1. loc_912A:               ; XREF: Obj28_Index
2.         ;flicky
3.         tst.b   1(a0)
4.         bpl.w   DeleteObject
5.         bsr.w   ObjectFall
6.         tst.w   $12(a0)
7.         bmi.s   loc_9180
8.         jsr ObjHitFloor
9.         tst.w   d1
10.         bpl.s   loc_9180
11.         add.w   d1,$C(a0)
12.         move.w  $32(a0),$10(a0)
13.         move.w  $34(a0),$12(a0)
14.         move.b  #1,$1A(a0)
15.         move.b  $30(a0),d0
16.         add.b   d0,d0
17.         addq.b  #4,d0
18.         move.b  d0,$24(a0)
19.         tst.b   ($FFFFF7A7).w
20.         beq.s   loc_9180
21.         btst    #4,($FFFFFE0F).w
22.         beq.s   loc_9180
23.         neg.w   $10(a0)
24.         bchg    #0,1(a0)
25.  
26. loc_9180:
27.         bra.w   DisplaySprite

But no mappings VRAM connector for a single animal. There is a multi VRAM connector at the end of this code here:

Code (ASM):

1. Obj28_FromEnemy:            ; XREF: Obj28_Ending
2.         addq.b  #2,$24(a0)
3.         bsr.w   RandomNumber
4.         andi.w  #1,d0
5.         moveq   #0,d1
6.         move.b  ($FFFFFE10).w,d1
7.         add.w   d1,d1
8.         add.w   d0,d1
9.         lea Obj28_VarIndex(pc),a1
10.         move.b  (a1,d1.w),d0
11.         move.b  d0,$30(a0)
12.         lsl.w   #3,d0
13.         lea Obj28_Variables(pc),a1
14.         adda.w  d0,a1
15.         move.w  (a1)+,$32(a0)   ; load horizontal speed
16.         move.w  (a1)+,$34(a0)   ; load vertical speed
17.         move.l  (a1)+,4(a0) ; load mappings
18.         move.w  #$580,2(a0) ; VRAM setting for 1st animal
19.         btst    #0,$30(a0)  ; is 1st animal used?
20.         beq.s   loc_90C0    ; if yes, branch
21.         move.w  #$592,2(a0) ; VRAM setting for 2nd animal

But that is for all of them. Am I overthinking your directions or am I on the right track?

 

If you take a look at Pattern Load Cues.asm you'll see that there are only two animals for each zone being loaded:

Code (ASM):

1. ; ---------------------------------------------------------------------------
2. ; Pattern load cues - GHZ animals
3. ; ---------------------------------------------------------------------------
4. PLC_GHZAnimals: dc.w 1
5.         dc.l Nem_Rabbit     ; rabbit
6.         dc.w $B000
7.         dc.l Nem_Flicky     ; flicky
8.         dc.w $B240
9. ; ---------------------------------------------------------------------------
10. ; Pattern load cues - LZ animals
11. ; ---------------------------------------------------------------------------
12. PLC_LZAnimals:  dc.w 1
13.         dc.l Nem_BlackBird  ; blackbird
14.         dc.w $B000
15.         dc.l Nem_Seal       ; seal
16.         dc.w $B240
17.         ...

 

I do know that.

Code (ASM):

1.  
2. ; ---------------------------------------------------------------------------
3. ; Pattern load cues - SLZ animals
4. ; ---------------------------------------------------------------------------
5. PLC_SLZAnimals: dc.w 1
6.         dc.l Nem_Seal       ; seal
7.         dc.w $B000
8.         dc.l Nem_Flicky     ; flicky
9.         dc.w $B240

I get this too. I get the whole x20 /20 in a hex calculator. $B000 links with $580. $B240 links with $592.

Code (ASM):

1.    
2.         move.w  #$580,2(a0) ; VRAM setting for 1st animal
3.         btst    #0,$30(a0)  ; is 1st animal used?
4.         beq.s   loc_90C0    ; if yes, branch
5.         move.w  #$592,2(a0) ; VRAM setting for 2nd animal
6.  
7.  

But everything SEEMS okay. It is acting like they both are loaded on $B240. Is there a sequence of code that I am overlooking that is causing it to do just that?

 

Yep, it's me again.

*Does anyone know what may be the problem in this Sonic 2 coding in Obj41 (basically what I'm trying to do is get it so the character can bounce off a nearby spring without being on top of it by using a certain animation but it has no real effect so far):

Code (ASM):

1. loc_189A8:
2.     movem.l (sp)+,d1-d4
3.     lea (Sidekick).w,a1 ; a1=character
4.     moveq   #4,d6
5.     bsr.w   loc_1978E
6.     btst    #4,status(a0)
7.     beq.s   loc_189C0
8.     bsr.s   loc_189CA
9.  
10. loc_189C0:
11.     lea (off_18FE2).l,a1
12.     bra.w   AnimateSprite
13.     tst.b   $25(a0)     ; is Sonic on top of the spring?
14.     bne.s   loc_189CA   ; if yes, branch
15.     cmpi.w  #$23,anim(a1)       ; is hammer attack being performed?
16.     beq.s   Obj41_NoHammerAttack    ; if not, branch
17.     moveq   #0,d0           ; clear d0
18.     move.w  x_pos(a0),d0        ; load block's X-pos to d0
19.     sub.w   ($FFFFB008).w,d0    ; substract Amy's X-pos from it
20.     bpl.s   Obj41_XPositive     ; if answer is positive, branch
21.     neg.w   d0          ; otherwise negate d0
22.  
23.   Obj41_XPositive:
24.     cmpi.w  #$35,d0         ; is Amy within 35 pixels of the spring (X-axis)?
25.     bge.s   Obj41_NoHammerAttack    ; if not, branch
26.     move.w  y_pos(a0),d0        ; load springs's Y-pos to d0
27.     sub.w   ($FFFFB00C).w,d0    ; substract Amy's Y-pos from it
28.     bpl.s   Obj41_YPositive     ; if answer is positive, branch
29.     neg.w   d0          ; otherwise negate d0
30.  
31.   Obj41_YPositive:
32.     cmpi.w  #$35,d0         ; is Amy within 35 pixels of the spring (Y-axis)?
33.     bge.s   Obj41_NoHammerAttack    ; if not, branch
34.     bra.s   loc_189CA       ; otherwise make spring bouncing
35.  
36.   Obj41_NoHammerAttack:
37.     rts
38. ; ===========================================================================
39.  
40. loc_189CA:

* Question for Selbi, is your Text Code generator able to edit the character name in the Got Through Act quotes?

 

Code (ASM):

1.     cmpi.w  #$23,anim(a1)       ; is hammer attack being performed?
2.     beq.s   Obj41_NoHammerAttack    ; if not, branch

To:

Code (ASM):

1.     cmpi.b  #$23,(MainCharacter+anim).w ; is hammer attack being performed?
2.     bne.s   Obj41_NoHammerAttack        ; if not, branch

Technically yes, since that text is the same format as Zone Title Cards. I don't have an editor for it done yet though.

 

Still nothing. I don't think it's the hammer trigger that's causing the problems anyway, the same code is ineffective for other objects without it.

So I have a can of food and no can opener? :v:

 

This also answers the question I asked about a month ago, so thanks!

 

Ok. Collision.

move.b #$8,$16(a0)
move.b #$8,$17(a0)


This includes sonic hitting it right? Where in the animal code should I put it? My previous question stands as well, but not as important as this. You guys complain the hitboxes were too big, so I checked it and you all were right. I want to fix them. Can anyone help?

 

Uhh, first line of loc_90C0?

 

Ok, ok. So that is INDEED where it is.


loc_90C0:
move.b #$C,$16(a0)
move.b #$C,$17(a0) ;add???

However:

This is the height of the box for the flicky. That top part is the one giving everyone trouble, and is now giving me trouble. No matter what I do it won't go away.

 

$16(a0) and $17(a0) don't control the size of the hitbox (I think it's a hint for the engine to determine whether the object's sprites need to be rendered). The size of the hitbox depends on the collision response in $20(a0). Search for the Touch_Sizes label to see the sizes.

 

Ok. replaced the animal hitbox with the buzzbomber bullet.

move.b #$87,$20(a0)

My question now is...why does the $87 work?

 

Actually it's not the hitbox, but the colission flag. To see how it works, you should take a look at "TouchResponse".

 

Of which 6 bits are dedicated to the size of the hitbox.

 

Ack. I'm having a little trouble trying to figure out SonMapEd. According to this tutorial, I'm looking for a "Sonic dynamic pattern load cues.asm" in the folder "_inc", but alas I cannot find the .asm. Is the tutorial out of date? Is the disassembly out of date (according to this, that's a no)? Am I using the wrong disassembly altogether?

Being totally new to this, this isn't very encouraging. :|

 

The guide actually was made with the older disassembly in mind. This is what I did to get around it, I downloaded the older one, (more specifically, this) and after un-zipping the folder, and splitting the ROM, I opened up SonMapEd, and loaded the Sonic dynamic pattern load cues.asm file from the _inc folder. But, I think it was renamed in the SVN version... (I actually couldn't find it myself. :v Edit: you don't have to split the ROM, the folder is already in the zipped folder. :v:

 

Just quick content search and found them in the latest disassembly - the file is called "Sonic - Dynamic Gfx script" and it's in "_maps". I'm just updating the tutorial page now.