Basic Questions and Answers Thread

I don't know about SK disasm, but you can get DACs from flamewing's improved SK sound driver:


http://forums.sonicr...93


EDIT:


On second thought, these DACs are likely missing in SK (and S3K in turn). This is why S3K replaces few S3 songs with its own versions. Probably, due to other DACs added or lack of space.


So I think you won't find them in SK disassembly. Check out flamewing's driver then, I remember seeing original S3 samples there.

 

S&K/S3K has the original music for LBZ though...
Anyway, the link vladikcomper gave should have everything. Not sure which file is what though, sorry.

 

Oh I forgot to say that this is Sonic 1 and I'm using MegaPCM, is there any WAV files out there with those DAC samples?

 

You don't need to look for WAV files of those, because Mega PCM can play them in their original format.


Mega PCM supports two sound formats, one of them being 4-bit DPCM, just one used for S3/SK samples. So you can take samples from flamewing's driver or SK disassembly, and include them in your ROM as is. Just set 'dpcm' in playback flags for these samples (in MegaPCM.asm).


Converting them to PCM (wav-files) is not the best option, since they will become twice as big, while the quality remains the same.

 

Ok thanks but where in SK disasm are they (what file name)? They have a lot of different DAC samples in it and I don't know which ones are they.

 

Use this table for name conversion: http://info.sonicretro.org/SCHG:Music_Hacking/Voice_and_Note_Editing#Sonic_3_and_Knuckles.2FSonic_3D_Blast

 

I've been working on a co-op mode in Sonic 1 like the one in Sonic 2. I almost got everything done: I made it read the second joypad, I made the partner follow Sonic, it has its specific art, etc. However, there's a little problem I'm having now that of course is making me feel frustrated. By the way, that thing is making the partner detect the solid objects and making this partner stand/collide on them, but seems it does not work. I've been trying some methods, and some more, like: - Porting the solids code from Sonic 2 - Adapting the code from Sonic 2 to Sonic 1 Since I'm not very used with solid objects, I'd need a small help from someone who knows this. By adapting the code from Sonic 2 to Sonic 1 I mean that I tried to replace the following line in every label that SolidObject, PlatformObject, SlopeObject, etc had it: lea ($FFFFD000).w,a1 to lea ($FFFFD000).w,a1 bsr.s @Label lea ($FFFFD040).w,a1 @Label Nearly exactly how Sonic 2's works. But still nothing. Some information or help would be appreciated. Thanks!

 

Right, first thing's first, Sonic 1's character object SST address gets loaded within the collision routines themselves, for example, "SolidObject":

Code:

SolidObject:

        tst.b    $25(a0)

        beq.w    loc_FAC8

        move.w    d1,d2

        add.w    d2,d2

        lea    ($FFFFD000).w,a1        ; <-

        btst    #1,$22(a1)

        bne.s    loc_F9FE

        ...

Sonic 2 however, loads Sonic's SST address, runs the routine, and then loads Tails' SST address and runs the routine once again:

Code:

SolidObject:

    lea    (MainCharacter).w,a1        ; <- Player 1

    moveq    #3,d6

    movem.l    d1-d4,-(sp)

    bsr.s    +                ; <- running routine for Player 1

    movem.l    (sp)+,d1-d4

    lea    (Sidekick).w,a1            ; <- Player 2

    tst.b    render_flags(a1)

    bpl.w    return_19776

    addq.b    #1,d6

                        ; v running routine for Player 2

+

    btst    d6,status(a0)

    beq.w    SolidObject_cont

The same applies to multiple other routines which are associated with the characters and their physical involvement with the objects, additionally, you may have to alter each object's code itself, something such as the floating platforms call the routine "PlatformObject", and if Sonic happens to be on the platform, the object's routine counter is increased, and if Sonic is to walk off of it, its routine counter is decreased, if you were to have multiple characters jumping onto the sample platform, the routine counter has a chance to increase out of proportion. I recall this back when I did BroTro, there's a lot of objects to account for, make sure you sort them all out.

 

It seems I have stumbled into yet another issue. As stated on my update to the hack; I have imported both rain and ash objects to load in GHZ, MZ, SLZ, and SBZ: What happens is the stage loads garbed stars. This issue either might be caused because of the RAM address is wrong. Or, the screen can't handle everything. Please help if you can.

Code:

; ---------------------------------------------------------------------------

; Object 02 - Rain

; ---------------------------------------------------------------------------



obj02:								  ; XREF: Obj_Index

				moveq   #0,d0

				move.b  $24(a0),d0

				move.w  obj02_Index(pc,d0.w),d1

				jmp	 obj02_Index(pc,d1.w)

; ===========================================================================

obj02_Index:	dc.w obj02_Main-obj02_Index

				dc.w obj02_First-obj02_Index

; ===========================================================================



obj02_Main:							 ; XREF: Rain code

				addq.b  #2,$24(a0)			  ;go to next routine

				move.l  #Map_obj02,4(a0)		;Maps

				move.w  #$56E,2(a0)			 ;VRAM position

				move.b  #0,1(a0)

				move.b  #1,$18(a0)

obj02_Display:

				jmp	 DisplaySprite

				rts



obj02_First:

				jsr	 Obj02_Display

				move.w  #-$700,$10(a0)  ; make the object have a speed which moves it up quickly

				addq.w  #4,$A(a0)

				jmp	 SpeedToPos	  ; update the object's position (move the object)

				rts

Obj02Next_Func:

				addq.b  #2,$24(a0)

				rts

Obj02_Delete:

				jmp	 DeleteObject

; ===========================================================================

; ---------------------------------------------------------------------------

; Sprite mappings

; ---------------------------------------------------------------------------

Map_obj02:

		include "_mapsrain.asm"

	include "_mapsrain2.asm"

The screen shot: (The Ash code will be a carbon copy of Obj02, but with different ram addresses. Obj10 will be the space it uses)

[/CODE]

 

I'm afraid I don't have enough information to pin point exactly what's wrong, you haven't stated whether the ash has its own art or not, and if so, if it has been loaded to VRAM or not, and if so, where abouts.

Code:

        move.w    #$56E,2(a0)            ;VRAM position

Here, in VRAM at 56E x 20 = VRAM address ADC0, that is where the invincible stars art is loaded, I'm assuming you want the invincible art in your levels, so you should not be trying to load your art to there (if you are), and you shouldn't be setting your object to read from there (if you don't want it to display stars instead of your art).


Tell us more about the art, and where you might have loaded it to in VRAM (if you have), we need more information.

 

I'm using the rain art for a place holder in MZ, That part is cleared up now. The guide I followed on retro hack wasn't the greatest demonstration I've stumbled across. The RAM location I have used was this:

Code:

			 lea	 ($FFFFD5C0).w,a1	 ;Ram location for the object.

			 move.b #$02,0(a1)			 ;Load object 02

Now I put the move.b code in with it because I load the art with the resizing codes. I still feel like I'm missing something though. I have my mappings and the art that is supposed to load as well.

[/CODE]

 

I know that expression... It'd be best just to take my question down. I'll noodle about by myself until I figure this out...

 

The problem is more that you obviously don't know what you're doing. Even in such a simplistic object there's a number of mistakes and errors, and to be perfectly honest I firmly believe it would be a waste of time to detail them.


That's really an awfully programmed object.


Besides, if I may throw my two cents in the bottomless and ineffective well of wishes, you shouldn't follow guides that will only put in your hack the same broken stuff as so many other hacks probably already have if someone made a guide for them.


Try the basic asm tutorials, you'll learn more and faster than by following such guides. And maybe, when you won't depend on those guides any longer, you'll have the necessary knowledge to consider adding your own original ideas into your hack.

 

Even though your accusation is 100% that I have no prior knowledge, I have the art loading correctly now.

 

Well actually redhot, given the context and use of the object, it looks to be a feature that hangs around in a level semi-perminantly displaying, like the water surface, or the HUD, so I feel that he's right to use that place. I also feel that it's not the object that's the problem, the object is fine enough, it isn't up to scraps as it could be, but it should still work (which is does looking at the screenshot), the problem is the art and its VRAM space, this is the information we need in order to help, but until he gives us information regarding the actual art itself, and where in VRAM he's attempting to load it, noone can help.

 

Ah yes, if he is making it rain instantly, that's a sure thing. If making it rain later on, then the "FindFreeObj" would be a better option.

 

If the function returns the first free sprite (and all the ones after it are also free) then why not directly edit the VRAM sprite table it would be much easier than messing around with mapping and all that it would also reducing processing time because the mapping does not have to be decoded. This can be done since your sprite is 4x4 tiles or smaller.


Here is a good VDP doc that I would recommend


http://cgfm2.emuviews.com/txt/genvdp.txt


It has the sprites table format used by the VDP and many more useful stuff that should be read.


Also you need to add the tiles that are loaded to the Pattern Load Cues.


When adding the object to the PLC see to it that there is a free vram address and remember which address you picked and use the vram address you picked and divide it by 32 (each tile is 32 bytes uncompressed).


Also it sucks that the window plane hides plane a the window would have been perfect for rain and other overlays.

 

I shit you not, this is exactly what I did before I even noticed this post.