Basic Questions & Answers thread

This is to remove the water effects, if he wants to completely remove the water system he needs to remove palette loading for half of the screen (its in Vblank, or loc_B10) edit the Level game mode so it wont load water surface, underwater palettes etc. Keep in mind that SBZ3 is LZ4 in disguise so you will need to edit the water to load to LZ4 if you still want water in SBZ.

 

I'm a bit confused. What do you replace these with?:

Code (ASM):

1. @fail
2. @wait
3. @notmoving
4. @noflip

Help me out there, please?

 

What kind of disassembly are you working on, and which game? We can't help you without knowing where to help. =P

 

sinkdude: It also might be helpful if you edit your post to explain rather than making a new one, you've only got one post left.

 

This is a Sonic 2 disassembly (Xenowhirl's disassembly) I'm using.

 

These are local labels. Replace each @ with $$. It should do the trick. If (and only if) it doesn't work, replace them with completely new names. You could take the first label that comes before which doesn't start with @/$$, append _ and the name of the local label, e.g. @iswood in Cat_Main would become Cat_Main_iswood.

 

I'm rather late, but here goes:

I believe the first line stops all scrolling. The second line, however, sets the left screen lock to the current camera X position - in other words, if you execute that line every frame, it stops you moving the screen to the left.

To set any screen lock to an arbitrary value, use the following words:

F728 - left
F72A - right
F72C - top
F72E - bottom

Note that right and bottom refer to the maximum camera positions, NOT the position of the screen. So if you want to make sure the screen never shows anything after x-position $8000, you need to instead set it to $7EC0 (which is $8000 - $140, $140 being the width of the screen). Same for bottom - the height of the screen is $E0.

Also note that when setting any of these values to something "inside" the screen (e.g. if the screen is at x-position $400 and you set the left lock to $420, or you set the right lock to $500, etc), the graphics will screw up. If you happen to be changing the bottom screen lock you can avoid this problem by writing the value to F726 instead, which causes the screen to scroll up gradually, but this behaviour isn't implemented for the left, right and top locks (in SATSEE, I actually went to the effort of implementing it, and it really helped).

 

I am trying to use PlaneED to make a title screen for Sonic 1. It however doesn't like what I have set up:

Which would be the right way so everything works okay?

 

Try something like this:

 

By using this already finished project file xP:

Code (Text):

1. ; provided by Selbi, adapted for main folder
2. Palette File: pallet/title.bin
3. Mapping File: mapeni/titlescr.bin
4. Art File: artnem/titlefor.bin
5. Mapping Compression: Enigma
6. Art Compression: Nemesis
7. Palette Length: 0x20
8. Palette Offset: 0x20
9. x-Size: 34
10. y-Size: 28
11. Tile Offset: 0x200

EDIT: Beaten by Mikel, but 600th posts. =D

 

Holy crap it works. Thanks!

 

Alright, so I'm having trouble with an Orbinaut randomly disappearing; that is, not appearing when it should when Sonic comes across it.

By adding sound effects to its code, I'm able to determine what it's doing and when, and I was able to prove that it's definitely loading the Orbinaut properly, but it's getting deleted incorrectly for some reason.

There are only 3 places in the Orbinaut's code that can delete it.

It's not this one (I tested using SFX like I said):

Code (ASM):

1.  
2. Orb_Delete:
3.                 bra.w   DeleteObject
4.  

So it must be one of these two:

Code (ASM):

1.  
2. Orb_MoveOrb:    ; Routine 6
3.                 movea.l orb_parent(a0),a1
4.                 cmpi.b  #id_Orbinaut,0(a1) ; does parent object still exist?
5.                 bne.w   DeleteObject    ; if not, delete
6.  

or

Code (ASM):

1.  
2. Orb_ChkDel2:    ; Routine 8
3.                 bsr.w   SpeedToPos
4.                 tst.b   obRender(a0)
5.                 bpl.w   DeleteObject
6.                 bra.w   DisplaySprite
7.  

The thing is, those last 2 are routines that only the satellites are supposed to perform, not the Orbinaut itself. So how can it possibly happen?

Well, the code that makes the satellites is this:

Code (ASM):

1.  
2. @makesatellites:
3.                 bsr.w   FindNextFreeObj
4.                 bne.s   @fail
5.                 addq.b  #1,(a3)
6.                 move.w  a1,d5
7.                 subi.w  #$D000,d5
8.                 lsr.w   #6,d5
9.                 andi.w  #$7F,d5
10.                 move.b  d5,(a2)+
11.                 move.b  0(a0),0(a1)     ; load spiked orb object
12.                 move.b  #6,obRoutine(a1) ; use Orb_MoveOrb routine
13.  

Is it at all possible that the FindNextFreeObj routine...

Code (ASM):

1.  
2. FindNextFreeObj:
3.                 movea.l a0,a1
4.                 move.w  #$F000,d0
5.                 sub.w   a0,d0
6.                 lsr.w   #6,d0
7.                 subq.w  #1,d0
8.                 bcs.s   NFree_Found
9.  
10.         NFree_Loop:
11.                 tst.b   (a1)
12.                 beq.s   NFree_Found
13.                 lea     $40(a1),a1
14.                 dbf     d0,NFree_Loop
15.  
16.         NFree_Found:
17.                 rts    
18.  

...could be failing somehow, so that a1 isn't changed to a new object slot, but remains the parent Orbinaut, causing it to turn itself into a satellite rather than creating a new object?

I don't know enough about it to tell.

Has anyone else ever had this problem when making layout hacks before?

Thanks.

 

I never had any problems with loading enemies. What I would do is to replace it with an older version of the code (like the June 2005 one). If it's not happening anymore, it's a problem with the SVN disassembly, otherwise, I don't know what to do.

 

Nope, I highly doubt that's the cause. What you can do to figure out exactly what's deleting the orbinaut is store the address inside the object RAM area in which the orbinaut's been loaded in some unused RAM variable ($FEB2 should do), and then trace all read/writes to that address (using Gens Tracer or the latest version of Gens Movie). That's allow you to figure out exactly which routine's behind the deletion.

EDIT: Actually it'll most likely be DeleteObject which does the actual deletion so that won't really help you. What you can do is add some code at the beginning of DeleteObject like so:

Code (ASM):

1.         cmp.b   #$60,(a0)   ; is it an orbinaut which is being deleted?
2.         beq.s   *   ; if it is, hang the game
3.         ; otherwise rest of DeleteObject code goes here

and then do a stack trace when the game hangs to figure out which part of the code is responsible for calling DeleteObject.

EDIT 2: Gah, I'm not thinking straight. Just add the following at the beginning of DeleteObject:

Code (ASM):

1.         cmp.b   #$60,(a0)   ; is it an orbinaut which is being deleted?
2.         bne.s   @cont   ; if not, continue
3.         move.l  (sp),($FFFFFEB2).w  ; otherwise, store the address to which DeleteObject is supposed to return to
4.  
5. @cont:
6.         ; rest of DeleteObject code goes here

Of course this won't give the exact return address if DeleteObject was bra'd or jmp'd to instead of bsr'd or jsr'd, but it'll still help.

 

I just beat MHZ and I am surprised no one mentioned the 3D effect on the boss, where the spikeballs and the thing above them are getting a 3D rotation. How is this possible? Is it animated art, simply swapping sprites or maybe there is a built in 3D engine like Snes MMX2 does with the title screen?

 

I believe they're just three simple sprites showing different sized spike balls

 

with the rear spikeball moving slightly slower than the middle spikeball moving slightly slower than the front spikeball, hence giving the 3D effect. It's basically parallax scrolling applied to those sprites.

 

Same with the top part between the pillars (scroll parallax), etc. It's some major parallax cheating, period.

 

Probably a simple question, but I want to know anyhoo. I was trying to make the 'Jumping Chemicals'(Object 1D) in Chemical Plant look Normal in Death Egg Zone. I was thinking I was supposed to simply find which tiles it uses in CPZ, find those tiles in DEZ, and edit those DEZ tiles in the same location to look like the tiles in CPZ. How would I go about doing this with the SVN Disassembly?

 

The art isn't part of the level art, it's in a separate file. It's loaded by the PLC; this is from Chemical Plant's second PLC:

Code (ASM):

1.     plreq $8780, ArtNem_CPZDroplet

In DEZ, it would overlap Silver Sonic's art, which starts at $7000 and takes $1B20 bytes. If you don't need Silver Sonic's art, remove its entry in the PLC and copy the above entry in DEZ's PLC. Otherwise, you could replace the $8780 above with $8B20 and add some code to object 1D to load different art in DEZ; replace this (in Obj1D_InitBall):

Code (ASM):

1.     move.w  #$643C,art_tile(a1)

with this:

Code (ASM):

1.     move.w  #$643C,art_tile(a1)
2.     cmp.b   #death_egg_zone,(Current_Zone).w
3.     bne.s   +
4.     move.w  #$6459,art_tile(a1)
5. +