Basic Questions & Answers thread

GT Koopa, concerning your object deleting problem, you should use the technique that is used in several objects, which is quite lengthy but works well with the object manager (except if the object moves...):

Code (ASM):

1.         move.w  8(a0),d0
2.         andi.w  #$FF80,d0
3.         move.w  ($FFFFF700).w,d1
4.         subi.w  #$80,d1
5.         andi.w  #$FF80,d1
6.         sub.w   d1,d0
7.         cmpi.w  #$280,d0
8.         bhi.w   DeleteObject

I took this code from the monitor object (Obj26_Display), but you'll find several other objects with the same code. You can also use that exact code to delete an object when it's too far off-screen (not immediately off-screen).

If your object is a badnik though, you'll have to deal with the "permanent state" stuff (Remember Sprite State flag in SonED 2). Look at the Moto Bug (object 40) for an example. Notice how MarkObjGone does the same thing as the code snippet I pasted, except it marks the object as "deleted" before actually destroying the object. This will tell the object manager to not load the object when you scroll away and back. The Moto Bug object "contains" the routine MarkObjGone so it doesn't call it, it just "falls through" to it; however, in your object, you should call the routine with bsr/jsr (or bra/jmp if the following instruction would be rts) where you currently have your deletion check.

 

Ok, quick question. I'm trying to hack Erasel's S2b disassembly. Well what is the level files format? They're all in .dat format, but when I try to edit them, the chunks are in weird places. Thanks

 

In what way are you trying to edit the .dat files, exactly? :/

 

That's because the level files tell the game where to draw the chunks >_>

It should be openable in a HEX editor, editing the numbers changes the tile numbers. You might want to make yourself SonEd2 Projects if you don't understand HEX editing at all.

 

IT WORKED! I can't believe it. Now I have to study HOW it worked.

 

Alright, I don't have a scrap of experience in hacking games, so when I ask this purely hypothetical question it's going to sound laughable to the hackers here. Having said that, since this thread seems to focus on modifying Sonic ROMs - how difficult would it be to hack a ROM of Gunstar Heroes to import music/graphics from Sonic games, or import new assets (e.g sprites) entirely?

 

Probably too hard unless there actually is a disassembly for Gunstar Heroes, while cool, doesn't exist. My dream idea is similar to this, with taking Desert Speedtrap and turning it into a Sonic game. However, the closest I could do that is possible is give Desert Speedtrap quirks and going ons into a Sonic game, most likely Sonic 1. However, I am currently working on Flicky Turncoat DX, so the project is shelved.


------------

However, this nudging away object of mine, while now deletes properly, is still nudging away left, too slow to fix by adding a 2 instead of 1. While I'm at it, it should NOT NEED fixing to my knowledge, yet here it is malfunctioning. The only idea I got is that it has to do with the fill timer portion and the counters in general. Something's not even.

Code (ASM):

1. ; ---------------------------------------------------------------------------
2. ; Object 45 - Cupcake
3. ; ---------------------------------------------------------------------------
4.  
5. Obj45:                  ; XREF: Obj_Index
6.         moveq   #0,d0
7.         move.b  $24(a0),d0
8.         move.w  Obj45_Index(pc,d0.w),d1
9.         jmp Obj45_Index(pc,d1.w)
10. ; ===========================================================================
11. Obj45_Index:    dc.w Obj45_Main-Obj45_Index
12.         dc.w Obj45_Rover-Obj45_Index
13.         dc.w Obj45_Roveralso-Obj45_Index
14.         dc.w Obj45_Display-Obj45_Index
15.        
16.        
17. ; ===========================================================================
18.  
19. Obj45_Main:             ; XREF: Obj45_Index
20.     addq.b  #2,$24(a0) 
21.     move.w  #$50,$30(a0)
22.     move.w  #$10,$32(a0)
23.     move.w  #$0000,2(a0)        ; moves #$0000 to the art tile's SST (it's 2 in S1 and S2)     
24.     move.l  #Map_obj45,4(a0)    ; moves the mappings into the mapping's SST    
25.     move.b  #$20,$19(a0)       
26.     move.b  #4,1(a0)    ; use screen coordinates (such as the ones you see in debug mode)      
27.     move.b  #4,$18(a0)  ; set priority
28.     rts
29.    
30.    
31.    
32. Obj45_Rover:        ; XREF: Obj45_Index
33.     addq.b  #2,$24(a0) 
34.     subq.w  #1,$30(a0)
35.     cmpi.w #-$50,$30(a0)
36.     beq.s   Obj45_Rovfill
37.     bsr Obj45chanters
38.    
39. Obj45_Roveralso:    ; XREF: Obj45_Index
40.     addq.b  #2,$24(a0) 
41.     subq.w  #1,$32(a0)
42.     cmpi.w #-$10,$32(a0)
43.     beq.s   Obj45_Rovfillalso
44.     bsr Obj45chanters2
45.  
46.    
47. Obj45chanters:  
48.     cmpi.w #0,$30(a0)
49.     bgt.s      Obj45_Rover2
50.    
51.     cmpi.w #0,$30(a0)
52.     ble.s      Obj45_Rover3
53.    
54. Obj45chanters2:
55.     cmpi.w #0,$32(a0)
56.     bgt.s      Obj45_Rover4
57.    
58.     cmpi.w #0,$32(a0)
59.     ble.s      Obj45_Rover5
60.    
61.    
62.    
63. Obj45_Rovfill:  
64.     move.b  #$C9,($FFFFF00A).w; play sound
65.     move.w #$50,$30(a0)
66.     bsr Obj45chanters
67.    
68.  
69. Obj45_Rovfillalso: 
70.     ;move.b #$C7,($FFFFF00A).w; play sound
71.     move.w #$10,$32(a0)
72.     bsr Obj45chanters2
73.    
74. Obj45_Rover3:          
75.     subq.w  #1,8(a0)   
76.     rts
77.    
78. Obj45_Rover2:      
79.     addq.w  #1,8(a0)   
80.     rts
81.    
82. Obj45_Rover5:      
83.     subq.w  #2,$C(a0)
84.     ;temporary solution, if 1 object flies downward at fast pace.
85.        
86.  
87.         jsr Obj45_Display
88.    
89.    
90. Obj45_Rover4:      
91.     addq.w  #1,$C(a0)
92.    
93.    
94.    
95.    
96. Obj45_Display:     
97.     move.b  #2,$24(a0)
98.    
99.    
100.     move.w  8(a0),d0
101.     andi.w  #$FF80,d0
102.     move.w  ($FFFFF700).w,d1
103.     subi.w  #$80,d1
104.     andi.w  #$FF80,d1
105.     sub.w   d1,d0
106.     cmpi.w  #$280,d0
107.     bhi.w   DeleteObject
108.    
109.     jmp DisplaySprite
110.         ;jsr        ChkObjOnScreen
111.         ;tst    1(a0)
112.         ;bpl.w  DeleteObject
113.  

 

Quick question before I go into hiding to get my hack finished, what's the location for the subroutine in Xeno's S2 disasm involving being hit by a badnik/spikes/projectile? I'm having one hell of a time trying to find it on my own.

 

Look at Touch_Loop and Touch_ChkValue. Objects that want to hit Sonic/Tails set their collision_flags ($20) SST value to an index into Touch_Sizes to select the hit collision size, combined with $40 or $80 or both to select from reaction routines Touch_Enemy/Touch_Special/Touch_ChkHurt. Some things like spikes skip all that and branch to Touch_ChkHurt2 directly after doing their own collision checking.

 

Ok, does anyone know what the format for the Sega PCM in Sonic 1 is? I'm hoping to be able to replace it with another PCM, and I need the exact info. If I recall, wasn't it something like 8000 Hz sample rate, mono?

 

PCM 22,050hz 8-bit mono

 

Actually, it's 16,000 Hz, 8-bit unsigned, mono.

 

I got a question releated to assembling itself: Is it possible to get the size in bytes of the ROM which has been assembled so far? I want to set a constant to the size in bytes at the point I'm setting that constant. Let's say, after $10000 bytes which've been put into the assembled ROM we come to this point where the constant is being set. I want to get the value to be loaded into that constant. Best would be some macro way.

 

The only thing I can think of what you mean is something like...

Code (ASM):

1.         Location:   move.l  #Location,d0

...where the offset location of that "move" command is moved into d0.

Could you perhaps rephrase?

Oh snap, I could've sworn it was 22,050 =%

 

I'm having issues with my water pallet for mystic cave zone. I had the water pallet working fine by using hidden palaces water code and pallet which I renamed for mystic cave. this worked fine up until I ported the sonic 1 sound driver but now regardless of what pallet I tell it to load mystic cave is loading this weird off-color mess. Chemical plant and aquatic ruin are working fine with any water pallet and I even tried to swap chemical plants pallet call with mystic cave zones with no success (it did use mystic cave's pallet on chemical plant though) so I'm figuring there is someplace else in the assembly I've missed. but searching the forums and the assembly to try and figure out what it is hasn't yielded any results. Sorry if I overlooked the solution.

 

* — but this is more appropriately "current address," so if you changed phase, it gets complicated (or may no longer be useful).
For example:

Code (ASM):

1.     dc.b    "SEGA MEGA DRIVE "
2.     dc.b    "PIETRO GAGLIARDI"
3. ; ...
4.     dc.l    $20202020, $20202020, $20202020; no SRAM
5.     ds.b    $1F0-*              ; because I don't know how many bytes are here
6.     dc.b    "JUE             "

The Intel/Z80 equivalent is $:

Code (ZiLOG Z80 Assembler):

1.     di
2.     im 1
3.     jp main
4.    
5.     ds 38h-$
6. interrupt:
7.     ; ...
8.     reti

 

This isn't related to hacking or Sonic exclusively, but I've tried Google searches and come up with nothing...

I'm having trouble finding an image of a Gameboy Advance pallet. I know there's a list of the generic 8 bit pallet (256 colors, all monotone) out there, so I thought all the lower-end devices had set pallets like that, but after looking through Google searches that have led to several places, I can't manage to find one. Part of the problem is that I don't know what I'm looking for at all, I don't know what bit the GBA is (I thought it was either 16 with a custom pallet or 24) or what I'm looking for that could replicate it, so I was wondering if anyone knew anything about it here, or if not, if there's a way I can rip the pallet from a GBA emulator?

I'd rather not rip it from an emulator though, since I think the emulators are a little off in their color pallets (Somewhere someone did confirm the Genesis emulator messes up the pallet colors in comparison to the original Genesis) but I might be stuck with that option if I can't find an authentic one.

Sorry if I'm asking a stupid question but this isn't something I'm entirely familiar with (and Wikipedia didn't help me. :v

 

AFAIK, the GBA has a 15-bit RGB palette, meaning it looks something like this:

No computer "is" a bit. Their internal chips are often said to "be" a certain number of bits based on the size of their data buses (I.e. how many bits they can manipulate at a time), and console makers back in the 90's would just describe their products based on the chip (usually the CPU, but not always) that made the whole thing sound better. It's basically a very poor way to describe consoles/computers. Anyway, that number has nothing to do with palettes. When you say that a palette is X bits it means that it has 2^X colors, so in the case of the GBA that's 32768 colors. After that you need to know what color space is used and how many bits are assigned to each component. The GBA uses the RGB color space, with 5 bits for each component (meaning that each of them can vary from 0 to 31).

I believe that the difference you talk about has to do with the type of the screen used to display the graphics. The GBA has a fairly faint LCD screen (not sure about the backlit ones), so the colors will obviously not look the same in your monitor. You could probably edit the palette to make it look more washed out to simulate a real GBA screen. The same is true for the Genesis... Not all televisions are the same, and NTSC is not particularly known for its color accuracy, so there will be significant variation no matter what you do.

 

Oh...

So for each bit something has, that's equal to 2 colors? Or am I not getting it?

I did a bit of reading about the difference in GBA and GBSP pallets actually, while I couldn't find the pallets themselves, I found a picture example of each. The first picture looked similar to the Genesis emulated colors with a darker white and darker colors in general, the second was (according to the article) the same pallet but lighter to adapt to the back light.

Thanks for the info. I was hoping to do something with the GameBoy pallet, or the colors used in Sonic Advance, in a Genesis game, but the pallet is too big to work with for even drawing authentic GBA sprites... Oh well. :v: