Basic Questions & Answers thread

TTTHHHHAAAAAANNNKKK YYYYOOOOUUUU. I had no idea that SonEd2 could work with another disassembly, that helps a lot to know that. I will try it when I get home later.

In the mean time, maybe someone can help me change EHZ's background graphics as I had requested earlier.

 

Ok, so I got this wrong number of operands error pointed at the dc.w lines. In order to fix it what should I do? Also should I not name these labels special names?

 

Ok, I tried Markey's SonEd2 setup and it worked nicely. I was able to edit levels with SonEd2 and build them just fine. However, I am still unable to edit any graphics without disaster.
Can someone please help with this? Specifically Plane B's background graphics as I have already requested.

 

In order to edit the background (or B plane) using SonED, the "P" key is what you'll need to press to view and edit the background's "layout", the chunks, blocks and tiles for the background though are held "with" the foreground chunks, blocks and tiles, and can be edited using the in-app editor by pressing the "I" key (Editing the BG plane from there on is the same as editing the FG plane, just "L" for the FG layout and "P" for the BG layout).

As for the "disaster" issue with your graphics, would you provide a screenshot for us please? It may help narrow down what kind of issue you have =)

 

Thanks but you don't seem to understand.
I don't want to edit the mapping, I want to edit the graphics. Lets say hypothetically I want to draw my own background graphics. I want to change the grassy fields and hills and clouds to something entirely different, like the inside of some ruins or industrial park. How would I, after drawing my own background graphics, replace the game's background graphics?

 

One thing I missed earlier: Don't put # in front of your numbers when using the DC directive.

I think you misunderstood. The Breathfire+2 and Breathfire+4 aren't meant to be label names, but what you'd use to address the other two words in your table. Here, an example:

Code (ASM):

1. Start:
2.     move.w  Table(pc),(a1)+ ; assuming a1 already contains our target location
3.     move.w  Table+2(pc),(a1)+
4.     move.w  Table+4(pc),(a1)+
5.  
6. Table:
7.     dc.w    $100
8.     dc.w    $200    ; Table+2
9.     dc.w    $300    ; Table+4
10.  

As you can see, I only use one label to read the data and add an offset for the other two words. Now let's do this in a loop:

Code (ASM):

1. Start:
2.     moveq   #3-1,d0         ; loop counter
3.  
4. Loop:
5.     move.w  d0,d2           ; copy current index in table
6.     add.w   d2,d2           ; scale to word size
7.     move.w  Table(pc,d2.w),(a1)+    ; write data at table index d0, a0 = target, postincrement
8.     dbf d0,Loop         ; keep looping as long as d0 isn't 0
9.  
10. ;...
11.  
12. Table:
13.     dc.w    $100    ; 0
14.     dc.w    $200    ; 2
15.     dc.w    $300    ; 4
16.  

After this loop the memory pointed to by a1 will contain the word sequence $300, $200, $100 (since the loop counts down). Here I see another small problem with your loop. It always writes to the same place ( x_vel(a0) and y_vel(a0) ). I assume you want to create three separate objects that move in different directions? For that you'd need to create a new object at the end of each loop.

 

I am trying to get badniks to change into ring monitors when Sonic has a special shield. I copied the code that loads small animals and changed #$28 to #$26.

Code (Text):

1. Obj27_LoadAnimal:        ; XREF: Obj27_Index
2.         addq.b    #2,$24(a0)
3.         bsr.w    SingleObjLoad
4.         bne.s    Obj27_Main
5.         move.b    #$28,0(a1); load animal object
6.         move.w    8(a0),8(a1)
7.         move.w    $C(a0),$C(a1)
8.         move.w    $3E(a0),$3E(a1)
9.         cmp.b    #2,($FFFFFE2C).w; Does Sonic have the particle shield?
10.         bne    Obj27_Main; If not, branch
11.  
12. Obj27_LoadMonitor:            ; copied code
13.         move.b    #$26,0(a1); load monitor object
14.         move.w    8(a0),8(a1)
15.         move.w    $C(a0),$C(a1)
16.         move.w    $3E(a0),$3E(a1)

Right now, the code makes blank monitors, but I want them to be ring monitors. I'm not sure how to fix this. And for some reason the animals don't appear when I use this shield.

 

To make a ring monitor you should set monitor's subtype (byte $28):

Code (ASM):

1.     move.b  #6,$28(a1)    ; set monitor subtype to #6 (ring)

As for the animals, the reason they don't appear is because you simply replace loaded animal with a ring monitor. To fix this, you can put "jsr SingleObjLoad" before "move.b #$26,0(a1); load monitor object".

 

Thanks for the help. Now I'm getting ring monitors and animals. And I was able to fix the rest of the problems myself. So, thanks.

 

The OOZ boss is being tricky. Sound and flashing errors up the wazoo. Normally I would put my speed up code between the "Boss hit" sound and the flash start.

Code (ASM):

1. move.w  #$AC,d0
2.     jsr (PlaySound).l
3.     cmpi.b  #4,collision_property(a0)
4.     bgt.s loc_2DAC6
5.     move.b  #1,($FFFFF102).w
6.     move.w  #$FB,d0
7.     jsr (PlayMusic).l   ; Speed up tempo
8.    
9. loc_2DAC6:
10.     lea (Normal_palette_line2+2).w,a1 ;flash
11.  

But the OOZ boss doesn't have that! I believe the code area I want could be in a out of boss code area, activated via a bsr or jsr. But where is it? My current solution is putting the boss pinch activator right at the beginning, but that is causing errors:

Code (ASM):

1.  
2. ; ----------------------------------------------------------------------------
3. ; Object 55 - OOZ boss
4. ; ----------------------------------------------------------------------------
5. ; Sprite_32F90:
6. Obj55:
7.     cmpi.b  #$4,objoff_32(a0)
8.     bne.s Boom
9.     move.b  #1,($FFFFF102).w
10.     move.w  #$FB,d0
11.     jsr (PlayMusic).l   ; Speed up tempo
12. Boom:
13.     moveq   #0,d0
14.     move.b  objoff_A(a0),d0
15.     move.w  off_32F9E(pc,d0.w),d1
16.     jmp off_32F9E(pc,d1.w)
17.  

 

Yes. Well, you could define it just about anywhere, really, but constants.asm is a good place to do it.

It's in _incObj\0A Drowning Countdown.asm a little ways under a comment saying "Sonic drowns here". The SVN as it stands says $17, not id_Drown... I guess I changed it reflexively.

Animation IDs really should be called something like ani_Drown, etc, but...

 

I would like to revisit this. I don't seem to get where exactly asr.w #1,d5 actually IS and where I can edit to change the friction. Thanks!

 

It isn't actually anywhere yet; that's why I said you can add it directly above the "move.w inertia(a0),d0" which is before the Obj01_SettleRight and Obj01_SettleLeft labels. Or you can add anything else there to change the value of d5 however you want.

 

As I am progressing in my Sonic 2 hack, I have come over a puzzling problem: modifying the CPZ spin tubes. What are the parameters for object $1E (CPZ Spin tube), and how does one modify the motion path of said spin tubes? Is it based on PLC? I tried to make a new spin tube, but, upon entering it, I was flung into a spin tube that I had previously deleted. I know that modifying it is possible, because I have seen it done in such hacks like S2RR. Thanks in advance for the help!

 

^ S2RR actually uses the original tube paths from Sonic 2.~

In any case, I know a little bit about these guys, but not much since I didn't bother to deal with them. The path you take out of tube entrances with two branches is determined by whether the timer's second is an odd or even value: the code takes the value from the seconds byte and does an immediate AND with 1. How many branches the tube has and the coordinates to travel to are determined by the subtype of the object, which references a table at byte_2266E for the number of branches and off_22980 and off_22E88 for the path coordinates (in the 2007 disassembly and possibly others, there are separate files included here).

I haven't really looked at off_22980, but off_22E88 starts with word-length pointers that are relative to the start of the pointer list (if you have a separate file, then think from the start of the file). After following this pointer, you'll encounter a word-length value for the number of bytes to read in followed by a list of coordinates, which are read as a word for the first x coordinate to go to and a word for the first y to go to, then a word for the second x and a word for the second y, etc., until you've read in the requested number of bytes. What stopped me in my tracks when I last checked years ago (and what I'm too lazy to research now) is that some sets of coordinates seem to be read backwards, starting from the last x and y and moving towards the first.

I've used many edited versions of the Metropolis zoom tube in S2RR, and that works on a similar premise: subtype for properties (whether or not to stop on exit, coordinates to choose, etc.), initial word stating the number of bytes, subsequent pairs of words detailing coordinates. It's much easier to deal with, though, because it doesn't have branches and doesn't change properties based on when you enter.

 

Alright, now taking this

Code (Text):

1. move.b    (Ctrl_1_Held_Logical).w,d0
2.     andi.b    #button_left_mask|button_right_mask,d0; is left/right pressed?
3.     bne.s    Obj01_Traction; if yes, branch
4.     move.w    inertia(a0),d0
5.     beq.s    Obj01_Traction
6.     bmi.s    Obj01_SettleLeft

and adding asr.w #7,d5 before the move.w inertia(a0),d0
to it works a treat for decreasing friction when you change the #1 to a #7. but I can't seem to find a way to increase the friction. You can't have less than 1, right? increasing the d5 to lets say d7 seems to have no effect, nor changing it to d3

Thanks again for helping me out here.

 

While modifying my layout for EHZ1 I came across a bug. When the level starts, the screen scrolls down (the starting point is the same as the original) and the same thing happens when you die - it scrolls from the top left of the level to the checkpoint you respawned from. The graphics also garble a little towards the end - cloud tiles seem to switch to what looks like signpost graphics. I'd like to point out both these problems started when I modified a section that is close to the starting point and adding a couple of floating platforms. Before this, it was fine and the level was completed layout-wise. Any clues on what is causing this?

I think I have seen this question before, but couldn't find it, so apologies if this is something well known.

 

You've placed too many rings.

Reduce the amount and it should go back to normal.