[Azu]

Anyone know where I can find tools to rip (and convert) and convert Sonic Adventure 2 GC models?

This post has been edited by Azu: 16 July 2011 - 08:08 PM

[MainMemory]

I'd be surprised if there are any tools for the GC version. I've considered writing an OBJ ripper myself, but the format is so much more complicated than SA1's...

[Azu]

What about for the DC version, I want to rip Metal Harbor and Pyramid Cave.

[Aerosol]

Someone told me about there being a way to get the SA2 level geometry from the DC version, so I know it's around. Don't remember much of what they said, though.

[Dr. Ed]

Question!!

keep in mind that I'm speaking from total ignorance so please excuse any stupid questions or assumptions.
This is something that I've never seen done, but it would seem that it would be more than possible...

shouldn't we be able to put custom mp3 soundtracks into s1,2,3&k?
When Team Megamix ported their project over to the sega cd, they effectively made a genesis game work for sega cd, right? My theory of what you guys did was that you ported your level layouts from megamix to sonic cd similar to what was done porting sonic one into sonic 2 in that sonic 1&2 hack from a while back and potentially sonic 1.2.3&k could be put into one game. Wouldn't that mean that Sonic 1, 2, 3&k could all be ported over to be played on sega cd? If that was the case and if someone were to use the same methods used to set bgm to mp3s then wouldn't we all finally have customizable mp3 soundtracks on genesis games? I'm aware of the work done on the pc version of s3&k for allowing mp3s to play as bgm.

I also know that the sonic retro channel sonic 1 used mp3s and I inserted my own mp3s into the game, but I'm pretty sure that was played on emulators as a genesis game.

I realize this would take some work to do that for all the genesis games but is seems like it's already been done for sonic 1.

anyway I was just curious and figured it couldn't hurt to ask if it was possible. If it is I may have to look into learning how to implement all of this, but it sounds like a pretty big project for someone with almost no rom hacking experience.

[GerbilSoft]

Dr. Ed, on 18 July 2011 - 09:37 PM, said:

shouldn't we be able to put custom mp3 soundtracks into s1,2,3&k?

There's a few ways to do this:

1. Use a hack such as S2MP3 or Retro Channel's MP3 plugin. This is the easiest to do, but it obviously only works on emulators (and only specific emulators).

2. Port the game to Sega CD. This requires extensive reworking, since the Sega CD has limited memory. (256 KB program RAM, 512 KB word RAM, and 64 KB system RAM from the Genesis itself.) Sonic CD essentially splits each level into its own minigame, complete with all the Sonic graphics and other common items. (This could be done at build time by incbin'ing the relevant source files into the final binary for each level, but it still requires massive reworking for the original games.)

3. Add Sega CD support without actually porting the game to Sega CD. This is known as "Mode 1" aka cartboot, and allows a standard Genesis game to control the Sega CD hardware. This works on real hardware, though you have to burn both an EPROM cartridge as well as a CD-R. The only emulator I know of that supports this at the moment is Kega Fusion.

[Azu]

Retro Channel's MP3 plugin only works with Sonic 1 at the moment though.

[Dr. Ed]

GerbilSoft, on 19 July 2011 - 01:40 AM, said:

Dr. Ed, on 18 July 2011 - 09:37 PM, said:

shouldn't we be able to put custom mp3 soundtracks into s1,2,3&k?

There's a few ways to do this:

1. Use a hack such as S2MP3 or Retro Channel's MP3 plugin. This is the easiest to do, but it obviously only works on emulators (and only specific emulators).

2. Port the game to Sega CD. This requires extensive reworking, since the Sega CD has limited memory. (256 KB program RAM, 512 KB word RAM, and 64 KB system RAM from the Genesis itself.) Sonic CD essentially splits each level into its own minigame, complete with all the Sonic graphics and other common items. (This could be done at build time by incbin'ing the relevant source files into the final binary for each level, but it still requires massive reworking for the original games.)

3. Add Sega CD support without actually porting the game to Sega CD. This is known as "Mode 1" aka cartboot, and allows a standard Genesis game to control the Sega CD hardware. This works on real hardware, though you have to burn both an EPROM cartridge as well as a CD-R. The only emulator I know of that supports this at the moment is Kega Fusion.

Thanks, that answers all my questions. Basically I want to make everything playable on real hardware(sega cd). I actually didn't know about the S2MP3 - or rather heard of it and completely forgot about it...

looks like my options are

2. which requires a lot of work (which I'll have to do a lot of research for, but hey that could be fun)
and
3. which requires less work and me actually ordering the tools in for it.

anyway I'm interested in doing something myself now. Now after a few years worth of toil and misery perhaps you'll hear from me again xp
off to the tutorials and snooping on other people's work...

[Elektro-Omega]

I asked this question a few pages ago but it went unanswered, not to worry though. Just asking again.

How would I go about programming a tile viewer for a sega megadrive / genesis rom?

I could make it game specific (by knowing the offsets) or just open to general roms but my first hurdle is how to display the raw data as tiles. If anyone can help me out with this it would be hugely appreciated.

[MainMemory]

This depends on what language and graphics library you use. In .NET you can copy 32 bytes directly into an 8x8 4bpp Bitmap, assign a palette to it, and use that for display.

This post has been edited by MainMemory: 19 July 2011 - 03:51 PM

[Elektro-Omega]

Thanks MainMemory. Initially I still have no idea but that is where the challenge is now that I know what direction to go in and how to approach it. Thanks again.

[Tamkis]

Well, guess what? I have another question (as usual).

Looking at the level select code for Sonic 2, I found a small routine that will write the sound test number when selecting a sfx in the sound test box (loc_965A/LevelSelect_DrawSoundNumber). I do not exactly understand this code, but how can I copy and modify this code so that it will write the copyright symbol on a tile on the VDP at, say, plane tile X,Y? Basically what I want to do is make the game replace a tile with the copyright symbol once a zone is ©ompleted, since the game is in a loop at the level-select menu. I've seen something similar done with the display of the grade results shown on the level-select in S3&K: The Challenges.

Below is a mockup showing what I want done for my hack

Before zone (EHZ) is completed:


After zone (EHZ) is completed:

[FraGag]

Tamkis, on 21 July 2011 - 07:36 PM, said:

Well, guess what? I have another question (as usual).

Looking at the level select code for Sonic 2, I found a small routine that will write the sound test number when selecting a sfx in the sound test box (loc_965A/LevelSelect_DrawSoundNumber). I do not exactly understand this code, but how can I copy and modify this code so that it will write the copyright symbol on a tile on the VDP at, say, plane tile X,Y? Basically what I want to do is make the game replace a tile with the copyright symbol once a zone is ©ompleted, since the game is in a loop at the level-select menu. I've seen something similar done with the display of the grade results shown on the level-select in S3&K: The Challenges.

Below is a mockup showing what I want done for my hack

Before zone (EHZ) is completed:


After zone (EHZ) is completed:

I suppose this only need to be done as the screen is loaded. If that is the case, we can use a relatively simple method to achieve that. The level select's foreground plane map is decompressed in RAM and stays there as long as the screen is loaded. It is used later on to highlight the currently selected level as you use the d-pad to change the selection. In your mock-up, the X and © symbols are highlighted, so I'll assume that's what you want. We can overwrite some parts of the in-memory plane map before it is sent to VRAM to be displayed.

; loc_92F6:
MenuScreen_LevelSelect:
	lea	(Chunk_Table).l,a1
	lea	(MapEng_LevSel).l,a0	; 2 bytes per 8x8 tile, compressed
	move.w	#make_art_tile(ArtTile_VRAM_Start,0,0),d0
	bsr.w	EniDec
	lea	(Chunk_Table).l,a1
	bsr.w	LevelSelect_DrawCompletedLevels ; <-- add this line
	move.l	#vdpComm(VRAM_Plane_A_Name_Table,VRAM,WRITE),d0
	moveq	#$27,d1
	moveq	#$1B,d2	; 40x28 = whole screen
	bsr.w	JmpTo_PlaneMapToVRAM	; display patterns

Add the line indicated above, then add the LevelSelect_DrawCompletedLevels routine somewhere:

LevelSelect_DrawCompletedLevels:
	move.w	#$1B,$50*3+$24(a1)
	rts

This simply overwrites the 1 (or X in your hack) next to EMERALD HILL with the copyright symbol (tile $1B). $50*3+$24 is the offset from the start of the in-memory plane map: $50 is the number of bytes per line ($28 tiles, which take 2 bytes each), 3 indicates that we want to write on the 4th line (the first line is 0), and $24 is the position of the tile * 2 (because there are 2 bytes per tile). I'll leave it to you to add tests/comparisons and branches and to figure out the offsets for the other Xes.

[Tamkis]

Just another quick question regarding sound porting: why do some of these pointers in the sfx pointer table (@ $1e4000) of MegaMan: Wily Wars (E) point backwards? The pointers should be pointing farther and farther away each time from the base offset $1d8000. I discovered this while running SMPSCalc on these pointers and noticed some extremely large size values for sfx (because it was going backwards).

Look at the picture below to see what I mean:


Is there another rule I need to know about SMPS z80(banked) sound porting regarding these "hiccups"? Or could this be something strange that is specific to MegaMan: The Wily Wars?
I would like to know what is up with that tonight if possible, because tonight I will be ripping MMWW's sfx, and I want to do it right.

[flamewing]

This is perfectly normal: they point backwards because the data is there. In some cases, this is because of a loop in the music/SFX; on others, they are re-using something (a set of voices, a music/SFX track) defined for an earlier music/SFX. This is also not unique to SMPS z80 (banked or otherwise) either -- SMPS 68k also has it.

For example: in S3&K, the sounds played when you get the fire, bubble and lightning shields use the same FM track data, which is defined only for the fire shield. The other two shields reference this, which mean they "point backward". If you are wondering, the differences between the 3 sounds are timing and instrument changes.