It could be an alpha channel effect for a mesh. Possibly some sort of aura or explosion. Heres my question. Imagine I have a game and I know where all of the offsets for the graphics are stored, how would I go about programming a viewer to view them. Bit of a hefty question I know but I've hit a wall between having the offsets and putting them to use.
Well, Sonic Loco 2 is almost ready for the hacking contest! All I have left to do is to get my music monitor working, and to change the titlecards (Selbi is working on getting S2TCG to work with the .svn version). Here is my attempt to create the code for my music monitor, which will change the current song to a hidden song. I just copied and pasted some offical code, and tried to modify it to suit my needs. BTW, I am using the Sonic 2 clone driver and am hacking Sonic 2. Code (ASM): music_monitor: move.b #MusID_FadeOut,d0 ; prepare to stop music (fade out) jsr PlayMusic ; Used to be bsr.w/s but "Jump too big", therefore I used jsr lea MusicList2,a1 move.b (a1,d0.w),d0 ; load from hidden music playlist for music monitor move.w d0,(Level_Music).w ; store level music jsr PlayMusic ; play level music, Used to be bsr.w/s but "Jump too big" rts For whatever reason, all the monitor does is play the slot sfx from CNZ. Why, I don't know. How can I make this monitor work correctly?
^ I don't know if you changed anything in the PlayMusic subroutine, but won't the value of d0 be the same every time you call that? You never change d0 based on what song you want, so it will always get data from the same spot in relation to a1.
Besides that (which is a quite bad mistake per se), his code wouldn't work as intended anyway even if he puts the correct song number in d0, because you can't invoke more than one new song per frame, at least in Sonic 1. I am not sure about Sonic 2 but I wouldn't assume it's much different. I forgot if the ignored song number is the former or the latter, though. Of course it's possible to force it to process an arbitrary number of song requests in a row, I know how to do it in Sonic 1, but I don't know how to do that in Sonic 2.
As Thorn said, you overwrite d0 with the ID to fade out music and never set it to another value. The ID to fade out music is then used as a (probably invalid) index into the list of songs. Given what I say below, you can actually cut the first call to PlayMusic here (and the line above it) without ill effects. Here is a rather long-winded technical explanation on how the S2 driver works in this regard: In the S2 sound driver, you can queue up to 2 songs and 2 SFX (1 normal, 1 stereo) in a single frame from the perspective of the M68K; that is about as much as you can ever queue, and if you try to queue more before the z80 can process these, all but the first song queued (the one in Music_to_play) will be overwritten. That is, as I said, as far as the M68K is concerned. When the queue is transferred to the z80 (this happens at every frame at V-Int), both SFX (and a third slot which is unused in the final S2) can be (separately) transferred to the z80 if their target slots in z80 RAM are empty; any that are not transferred will remain in the queue until it is either sent in another frame or overwritten by a further call to play SFX of that type. The first song (stored at Music_to_play) will be sent to the z80 only if the z80 is still not processing its queue (songs or SFX) from previous frames; it will remain on the queue until it is transferred: it will never be overwritten from the M68K queue until it is transferred to the z80 (the song in Music_to_play_2 will be overwritten instead). The song at Music_to_play_2 will only ever be sent to the z80 in two situations: Music_to_play is zero (because the song stored in it was sent in a previous frame and no other calls to play music were issued) and if the z80 is not processing its queue; or if the current song being played has a nulled out voice bank pointer (otherwise, the voice pointer will prevent it from ever being used since it has a (nonzero) byte on the same region of z80 RAM where the song would be queued). And even when it is sent, it will never ever get used because the z80 code does not check or use this byte except as a component of the voice pointer. In either case, it will remain queued until it is sent to the z80 (by either case) or until it is overwritten. The fact that case (2) even exists is a bug (with a trivial fix) that so far been undetected, and it will prevent the song from being played when it happens; for reference, if anyone wants to fix it, locate the following code: Code (ASM): loc_10C4: moveq #4-1,d1 and change it to this: Code (ASM): loc_10C4: moveq #3-1,d1 The z80 only processes one entry in the queue per frame (at V-Int); unprocessed entries remain in the queue.
Since I am using the Sonic 2 clone driver, which is basically a ported and modified Sonic 1 sound driver, couldn't we just pretend I am hacking Sonic 1 and try the Sonic 1 method for changing the level song by the music monitor? Also, I have been having some problems with SonMapED lately for hacking Sonic 2 art. I have been trying to edit the art of three nemesis compressed objects: rings, the SEGA logo, and Sonic's special stage art. Loading the nemesis-compressed tile graphics goes fine for all three objects, but when I load the corresponding sprite mappings for the first two objects, no sprites load in the editor. Sprites loaded for Sonic's special stage art, but they were garbled, so I loaded the corresponding DPLC mappings. But doing that made the mappings worse; some sprites had mappings pointing to unexisting tiles! So the question is, are these problems caused by SonMapEd, or are the sprite mapping files corrupt or incomplete? What am I doing wrong? Here are some pictures showing what I mean about the Sonic special stage mappings: Loading Nem-compressed Sonic Special Stage art: Loading Sprite mappings: Loading Sprite DPLC mappings:
You didn't get what I meant. To change the song in the middle of a level in Sonic 1 all you have to do is: Code (Text): move.b #$xx,d0 jsr PlaySound Where $xx is the song ID of the song you want to play. What you're trying to do is equivalent to: Code (Text): move.b #$E0,d0 jsr PlaySound move.b #$xx,d0 jsr PlaySound Where $E0 is the "song" ID of the fade out effect. In Sonic 1, you can't do this, because you're calling the PlaySound routine twice in the same frame. I just tested it, it doesn't work, as the first song ID is ignored, and only the second song ID is used (so if you put $xx first and $E0 afterwards, the old song will fade out, and the new song won't play). There's nothing special in "the Sonic 1 method for changing the level song by the music monitor", if you don't use the fade out effect. If you want to use it, then you need to alter the code to allow PlaySound to be called twice in a row, and probably you need to alter the fade out effect as well, to prevent the new song from starting until the old one has completely faded out. That said I am against the clone driver in Sonic 2 because you're using the 68000 to do something which should be on the Z80.
The SEGA logo is a plane-mapped graphic; SonMapEd can't handle it, but PlanEd can. The special stage art won't work -- SonMapEd can't handle the DPLCs for it. Quoting from the SVN disassembly: Moreover, the DPLCs alone aren't able to handle all the work because it expects extra hard-coded data on the RAM location of special stage art for Sonic, Tails and Tails' tails. I should write a tutorial on how to edit the disassembly so you can use normal DPLC instead.
Not to hog this thread (I ask too many questions :P), but I have a few questions regarding sfx porting. Lately, I have been trying to port sfx from MegaMan: The Wily Wars (E) into my Sonic 2 hack, MM2RW. Unless I am doing something wrong, after following the SCHG's Music Hacking guides direction, the ported sfx doesn't play in the Sound test or game once inserted into my Sonic 2 hack. Could the sound driver be rejecting the new sfx, or am I doing something wrong? Here is a sample of my steps to porting the sfx, using the first SFX (which I don't believe is null) as an example. Since MMWW has a SMPS z80 (banked) sound driver according to the SCHG's Music hacking guide, all pointers are in little endian. This means, according to the guide, that for example, a pointer reading "7880" should be mentally parsed as "8078" (correct?). For the data locations, the guide said: After opening the rom in a hex editor, I went to the pointer list at $1E4000, and found these pointers: Using the first sfx pointer as an example, I mentally parsed the first pointer to be $C120 ($20C1=$C120 in little endian). I then added $C120 to $1D8000, and got an offset value of $1E4120 for the start of the 1st sound effect. Lastly, I selceted and exported the data between the range of the starting offset ($1E4120) and the next pointer-1 ($1d8000+$C144=$1E4144, $1E4144-$01=$1E4143) Is there anything wrong in my porting process to cause the sfx not to play?
There is one thing, yes: for z80 pointers, you also have to strip bit 15 from the pointer before adding it to the address of the ROM bank: this is because the ROM bank in the z80 address space starts at address $8000. Using your example, your address $C120, when stripped of bit 15, becomes $4120. When added to the address of the ROM bank for SFX ($1D8000), it becomes $1DC120; this is $8000 bytes before what you obtained. There is the problem that you still will have to edit the SFX to fix pointers contained within it too -- or else, align it so that it is in the same position relative to your sound bank as it was on Megaman (I.e., $4120). This is complicated a bit by the fact that the header format described in the wikis is not accurate for SFX. There is also the issue of coordination flags: they may not be equal in those games, which adds additional challenges when porting.
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...
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.
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.
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...
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.
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.
