Basic Questions & Answers thread

Should be AnPal_3A42 in Stealth's disassembly.

 

Code (ASM):

1. AnPal_3A42: dc.w $EEC,$ECA,$EA8,$EEE,$EEE,$EEE,$CEC,$AEA,$2E0,$EEE,$EEE,$EEE,$AEC,$4EC, $CC,$EEE
2.                     ; DATA XREF: SuperSonic_PalFlash+15Ao
3.                     ; ROM:0005FD52o
4.         dc.w $EEE,$EEE,$CEE,$8EE,$4CE,$EEE,$EEE,$EEE,$EEE,$CCE,$AAE,$EEE,$EEE,$EEE,$EEE,$ECE
5.         dc.w $CAC,$EEE,$EEE,$EEE

Haven't tested it yet, but with those loads of whites ($EEE) I'm sure it's the correct stuff. Thanks. =)

EDIT: Yes, it is this thing. Thanks again.

 

Hi. I was wondering if it was possible to hack Sonic 2's Special Stage tube directions?

 

Where does the NoHammerAttack branch go, straight before the bounceUp branch or after ALL of the Obj 41 coding?

 

I am trying to create a level layout for Labyrinth Zone, and I want the water to stay at a constant level. As in, it doesn't rise at specific points. I looked in the main ASM file, and it says the default height is in the file lz_heigh.bin, but then there is the section below with the Dynwater_LZ1, which looks like this.

Code (ASM):

1.  
2. DynWater_LZ1:               ; XREF: DynWater_Index
3.         move.w  ($FFFFF700).w,d0
4.         move.b  ($FFFFF64D).w,d2
5.         bne.s   loc_3CD0
6.         move.w  #$B8,d1
7.         cmpi.w  #$600,d0
8.         bcs.s   loc_3CB4
9.         move.w  #$108,d1
10.         cmpi.w  #$200,($FFFFD00C).w
11.         bcs.s   loc_3CBA
12.         cmpi.w  #$C00,d0
13.         bcs.s   loc_3CB4
14.         move.w  #$318,d1
15.         cmpi.w  #$1080,d0
16.         bcs.s   loc_3CB4
17.         move.b  #-$80,($FFFFF7E5).w
18.         move.w  #$5C8,d1
19.         cmpi.w  #$1380,d0
20.         bcs.s   loc_3CB4
21.         move.w  #$3A8,d1
22.         cmp.w   ($FFFFF648).w,d1
23.         bne.s   loc_3CB4
24.         move.b  #1,($FFFFF64D).w
25.  
26. loc_3CB4:
27.         move.w  d1,($FFFFF64A).w
28.         rts
29. ; ===========================================================================
30.  
31. loc_3CBA:               ; XREF: DynWater_LZ1
32.         cmpi.w  #$C80,d0
33.         bcs.s   loc_3CB4
34.         move.w  #$E8,d1
35.         cmpi.w  #$1500,d0
36.         bcs.s   loc_3CB4
37.         move.w  #$108,d1
38.         bra.s   loc_3CB4
39. ; ===========================================================================
40.  
41. loc_3CD0:               ; XREF: DynWater_LZ1
42.         subq.b  #1,d2
43.         bne.s   locret_3CF4
44.         cmpi.w  #$2E0,($FFFFD00C).w
45.         bcc.s   locret_3CF4
46.         move.w  #$3A8,d1
47.         cmpi.w  #$1300,d0
48.         bcs.s   loc_3CF0
49.         move.w  #$108,d1
50.         move.b  #2,($FFFFF64D).w
51.  
52. loc_3CF0:
53.         move.w  d1,($FFFFF64A).w
54.  
55. locret_3CF4:
56.         rts

When I get to the time when I need to change the water levels, is this the correct section? Or is there a way to lock the water at a specific height all the way (excluding act 3, for the boss of course). Any help is hugely appreciated.

 

Yea, disable the function of Dynwater_lz1 by putting an RTS.
Another way you can do is change this line:

Code (ASM):

1.  
2. move.w  d1,($FFFFF64A).w
3.  

to a constant value.

 

Ok, now I seriously experimented with it, and this thing MUST work:

Code (ASM):

1. Obj41_Up:               ; XREF: Obj41_Index
2.         move.w  #$1B,d1
3.         move.w  #8,d2
4.         move.w  #$10,d3
5.         move.w  8(a0),d4
6.         jsr SolidObject
7.         tst.b   $25(a0)     ; is Sonic on top of the spring?
8.         bne.s   Obj41_BounceUp  ; if yes, branch
9.  
10.         tst.b   ($FFFFFFFF).w       ; is hammer attack being performed?
11.         beq.s   Obj41_NoHammerAttack    ; if not, branch
12.         moveq   #0,d0           ; clear d0
13.         move.w  $8(a0),d0       ; load springs's X-pos to d0
14.         sub.w   ($FFFFD008).w,d0    ; substract Amy's X-pos from it (Anything starting from $FFFFD000 Sonic's/Amy's RAM location)
15.         bpl.s   Obj41_Positive      ; if answer is positive, branch
16.         neg.w   d0          ; otherwise negate d0
17.  
18. Obj41_Positive:
19.         cmpi.w  #35,d0          ; is Amy within 35 pixels of the spring?
20.         bge.s   Obj41_NoHammerAttack    ; if not, branch
21.         bra.s   Obj41_BounceUp      ; otherwise make spring bouncing
22.  
23. Obj41_NoHammerAttack:
24.         rts             ; return

I fixed a few bugs that caused this thing to not work (I.e. I confused a .b with a .w, one of my usual problems). I also found the correct maximum distance between Amy and the spring. (#35 pixels (or $23 in hex)).
The only thing you need to do again is to replace the $FFFFFFFF with your flag (if you still have any troubles with this thing, it would be nice if you tell me what your flag is).

 

Thank you Hanoch. In the lz_height.bin file, the data for the water rising during the boss isn't there is it? I edited it just for the first act so far, but I'm just wary of doing damage to something as sophisticated as a boss when I get to Act 3.

 

Anybody knows how to load over $53 chunks in sonic 1? Chunk $54 is messed up in the gameplay.

 

The flag I believe is FFFFFFA4.

Okay tried it, it's fixed horizontally but not vertically, ie if you hammer directly below or above a spring from any distance you spring up (or hear rapid spring SFX if it is offscreen). May a branch for the spring and Amy's vertical position also be needed?

 

This should do it:

Code (ASM):

1. Obj41_Up:               ; XREF: Obj41_Index
2.         move.w  #$1B,d1
3.         move.w  #8,d2
4.         move.w  #$10,d3
5.         move.w  8(a0),d4
6.         jsr SolidObject
7.         tst.b   $25(a0)     ; is Sonic on top of the spring?
8.         bne.s   Obj41_BounceUp  ; if yes, branch
9.  
10.         tst.b   ($FFFFFFA4).w       ; is hammer attack being performed?
11.         beq.s   Obj41_NoHammerAttack    ; if not, branch
12.         moveq   #0,d0           ; clear d0
13.         move.w  $8(a0),d0       ; load springs's X-pos to d0
14.         sub.w   ($FFFFD008).w,d0    ; substract Amy's X-pos from it
15.         bpl.s   Obj41_XPositive     ; if answer is positive, branch
16.         neg.w   d0          ; otherwise negate d0
17.  
18. Obj41_XPositive:
19.         cmpi.w  #35,d0          ; is Amy within 35 pixels of the spring (X-axis)?
20.         bge.s   Obj41_NoHammerAttack    ; if not, branch
21.  
22.         moveq   #0,d0           ; clear d0
23.         move.w  $C(a0),d0       ; load springs's Y-pos to d0
24.         sub.w   ($FFFFD00C).w,d0    ; substract Amy's Y-pos from it
25.         bpl.s   Obj41_YPositive     ; if answer is positive, branch
26.         neg.w   d0          ; otherwise negate d0
27.  
28. Obj41_YPositive:
29.         cmpi.w  #35,d0          ; is Amy within 35 pixels of the spring (Y-axis)?
30.         bge.s   Obj41_NoHammerAttack    ; if not, branch
31.         bra.s   Obj41_BounceUp      ; otherwise make spring bouncing
32.  
33. Obj41_NoHammerAttack:
34.         rts             ; return

Being too lazy to test it, you need to find out the correct distance for the Y-axis by yourself (first line in Obj41_YPositive).

 

You would have to edit the game to load the chunks uncompressed from the ROM, because there's not enough RAM to load more chunks. If you wanted to have $80 256x256 chunks, you would have to take 100% of the RAM.

 

#35 actually seems to work fine. Thanx for that and sorry for what turned out to be a rather tricky code.

 

I decompressed the green hill zone mappings in kosinski format, and I removed this:

Code (ASM):

1.  ;bsr.w KosDec          ; mappings load uncompressed
2.  

So mappings load uncompressed, but nothing loads. Not even collision.

 

Ok, So now my SonMapEd program is working now, but now it says that whenever I build the ROM, It counts over 64 Errors. What is wrong here?

 

All that's left before that commented out command, is the location to the compressed chunks (and the ram location where it's getting dumped to) ..is being loaded into an address register each, that routine you commented out was responsible for taking the compressed chunks from rom location, decompressing them, and then dumping the uncompressed data to the ram location in small sections, I think the point that FraGag was trying to make is that you do not want to load the chunks from rom to ram, insted have them uncompressed in rom and set the engine to read it from rom, insted of ram.

So not only will you have more chunks to work with, you'll also have a "LOT" of free ram space to do with what you plead (If that makes any sense of course).

Is there a chance you could maybe show us what these errors are?

 

As Much as I would like to, I have no way of doing so. It was only when I checked the Process in the final stage of it building, it said 64 Errors found. I'm not sure what it is, but it doesn't even mention what's wrong with it either.

 

You can use Alt+PrintScreen to get a screenshot of the active window (or PrintScreen alone to get a screenshot of your whole screen); then open Paint or whatever program you have installed on your computer and paste (ctrl+v). Save in whatever format you're comfortable with and upload the pic on imageshack.

 

Or even easier, right click in the cmd -> Highlight (or whatever it is in english). Highlight the part you want, then click on the top of the window (that blue thing) with another right click and select "copy". Then you have you text in the clipboard and can paste it anywhere.

 

Once you selected the text you can just press enter to copy it.