Well, I'm now going to hack 1 of the "final frontiers" of Sonic hacking: Sonic 3 & Knuckles! Im using the current .svn disasm, but haven't begun to look inside the actual disasm file (sonic3k.asm, or something like that). With that in mind, please excuse me if the answers to my following 3 questions are obvious. #1: How/where in the disasm do you modify the PLCs for level art? For example, in AIZ1, I want to use the collaspable bridge object from AIZ2 without having garbled graphics #2: With SonED2, you can separately place where (Sonic &/or Tails) and Knuckles start. With that fact in mind, I decided to place 2 separate startimg points in AIZ1. The only problem is, Knuckles only starts at his special starting place once; after he dies without hitting a checkpoint, he starts at Sonic's/Tails' starting point. How do I fix this? #3: How do you modify the music in S3&K? Since, obviously, S3&K doesnt use the S1Snd Driver, you cant use xm3Smps Oerg. I know changing the music is possible, because S3 Megamix had Green Grove music for AIZ (See http://forums.sonicretro.org/index.php?showtopic=14121&st=720) Thanks in advance!
This might be a bit general, but hopefully some of it can at least point you in the right direction... In reverse order, for no satisfactory reason: #3: Importing Sonic 3D music is relatively straightforward because they share a very similar sound engine - you can just pull out the relevant S3D track, throw it in the right place in a bank, point to it and go (unless you pick one of the few tracks using different DAC samples, in which case you'd have to copy those over too.) Music from other sources? I wouldn't really know. #2: The level events cause all characters to pass an "invisible checkpoint" of sorts around the place that the proper level starts. This is so that Sonic doesn't have to repeat his intro if he dies. Look for the following within AIZ1_Resize: Code (Text): loc_1C522: move.b #1,(Last_star_post_hit).w move.w #$13A0,(Saved_X_pos).w move.w #$41A,(Saved_Y_pos).w jsr (Save_Level_Data).l move.l #0,(Saved_timer).w moveq #8,d0 jsr (Load_PLC).l addq.b #2,(Dynamic_resize_routine).w You'll need to do something to that section, or to avoid it, depending on exactly what you want to happen for each character. There's quite a lot of stuff in that routine, along with the AIZ1 Screen and Background functions, that you might want to mess with, including the artwork meddling and character-specific hackery involved in the intro scene transition (see also SpawnLevelMainSprites and Obj_84). #1: The main level tiles and PLCs are identified in a big fat data array called LevelLoadBlock. There is some degree of sorcery in its construction (by which I mean, the PLC references are not especially intuitive). If you compare LevelLoadBlock against Offs_PLC, which handily sits below it, you may be able to see a correlation. (Sorry if that's a bit vague; I've never touched the thing and I'm just going on what I can figure out by quickly scanning over it.)
I will only chime in to correct this: it is the exact same sound engine in terms of code. Most of the data is also the same (PSG tones, noise flutter, FM voices). I *think* that most of the SFX are also identical; I can't comment on the DAC samples, but the wiki claims that S3D has a subset of the S&K samples.
I didn't want to say that they were exactly the same without knowing; thanks for the clarification. I know from experience that some of the DAC varies: The Final Fight and the last beat of the S3D title theme sound wrong if imported directly, and possibly others I've forgotten. (I'm assuming it's DAC anyway.) ISTR there's a small number of different SFX too.
SonLvl should be able to change Sonic's start position, but I don't know how to make it work. And it won't let me select the Build and Run button. Can someone please tell me how to fix this? I also have one more question. Is there a quick way to clear all the chunks and objects from a level?
If you're not using an SVN disassembly, you'll have to do quite a bit of manual hex to make it work. Find the start location array in the ASM, write each set of values into binary files, and replace them with incbin/binclude directives, then add "startpos=../startpos/ghz1.bin:Sonic:Level Start" lines for each level in the INI, and make a definition for Sonic in obj.ini (look at the SVN disassembly for help). For "Build & Run", add two lines: Code (Text): buildscr=../build.bat romfile=../s1built.bin If you want to clear data from a level, you can simply delete the files, except for the palette files.
Thanks for the help. I downloaded SonLvl and the disassembly again and it worked just fine. The new path swapper graphics make it a lot easier to use. Will deleting the files change the size of the level, or will it keep the same dimensions?
In Sonic 1, the level data will be made the maximum allowed size, 64x8, the boundaries for the camera are separate and won't be changed. In Sonic 2, all levels are the same size, and the boundaries for the camera are separate and won't be changed.
Right. I want to start a Disassembly. Now, I don't have a huge amount of knowledge but I am not a complete newcomer. I am using IDA Pro 5.5 and a copy of Streets of Rage 2 (for experimentation). Now I have documented a large amount of offsets from Street of Rage 2 and jotted down their usage and start point and end point. My question is mainly the theory behind the disassembling. If I navigate to a specific offset (which I know the use of) and press C it should disassemble it into its ASM code. Is that literally all of the ASM code for that specific use? E.G - If I test it on where I am certain the palettes and disassemble, is the asm that is shown the functions that load the specific palette for the particular object? Also, side question, when going through IDA Pro, is it literally the repetative task of pressing down and C? I'm not sure if I'm being really stupid with this. I like to think I have some technical knowledge but I'm no expert at this. --- Edit: I am having trouble building a working rom from the ASM file. I get 'Illegal value', 'Bad Size On Opcode' and a lot of Illegal addressing mode errors.
Yes, right click in the chunk list in the tile editor window, and choose Insert Before/After, Import, Draw or copy and paste. If the counter at the left is at 100/100 you'll have to delete chunks first.
Not everything in the ROM is code; there is also raw data that is referenced by the code. Therefore, you can't just press C on every unknown block (otherwise, there wouldn't be a need for an interactive disassembler!). The best way to start disassembling a Mega Drive ROM is to begin with the vectors. The vectors are an array of 64 longwords at the beginning of the ROM. Press D 3 times at address 0 to turn the first vector (the initial stack pointer) into a dc.l, then press * (or click the * button on the toolbar) and create an array of 64 elements (I suggest specifying 4 items per line and 0 for the item width to make the array easier to read). Then, press O on a value in the array to turn all values in the array into offsets. All vectors except the first one point to code, so you can double-click a label in the vectors array and press C to disassemble the code at that location. The second vector (at address 4) is the initial program counter: this is the code that runs first when the console is turned on (possibly after running the TMSS). The other vectors are for exceptions and interrupts; of particular interest are the vector at $70, which is HBlank, and the vector at $78, which is VBlank. When you press C, IDA will disassemble as much code as it can. When it encounters a branch or a "static" jump (I.e. a jump that does not use an address register), it automatically follows the branch or jump and disassembles the code there too. However, it will stop when it encounters a "dynamic" jump, because resolving the targets of such a jump requires an understanding of the code and of the possible values for the registers used in the instruction. Some of those can be easy to determine: instructions of the form "jmp Label(pc,dX.w)" use an offset table starting at Label. Other are much harder to handle: instructions of the form "jmp (aX)" require you to figure out what values aX can take (and usually, it's read from RAM, so you need to find every piece of code that writes to that RAM area). If you press C at some point and the disassembled code doesn't end with a branch, a jump or a return instruction, there's a very high chance that it was NOT code. Press U to mark the data as undefined, or mark it as data if you understand its structure.
You could. EHZ has the maximum amount of chunks to start with though, so you will have to delete some. If you want EHZ to use all of HTZ's chunks, you can either find the code that loads HTZ's tiles and blocks, and change it to do it for EHZ too, or combine the files yourself. If you get LevelConverter, open HTZ, and export as Sonic 2 format, the Tiles and Blocks files will be combined for you (replace art/kosinski/EHZ_HTZ.bin with Tiles.bin and mappings/16x16/EHZ.bin with Blocks.bin).
I exported some chunks from HTZ to EHZ and now HTZ is all messed up! Is this a problem in loading the level, or is it a problem with the ROM? And how do you I use the slope solids? All I can use is simple square solids. My last question: Is it possible to import and and export the solidity of the chunks?
If you delete chunks from the list, SonLVL automatically changes the level layout for you, but not other levels/acts that use the same chunks. HTZ uses part of EHZ's chunks, and EHZ2 is likely messed up as well. You pick which solid type to use in the Blocks tab, find the block, and use the "..." buttons to pick a slope type for each path, or enter a number. You cannot import and export solidity information of chunks (at least not yet).
Quick question about SonMapEd: What is the internal limit to the amount of tiles SonMapEd can load from a tile art file? I'm asking because I am editing Knuckles main sprite art in S3&K, and after making the sprite edits, I have >$1000 tiles. Whenever I save all of the files that were opened pertaining to editing Knuckles' art (Uncompressed tile art, PLCs, and mappings) the mappings ignore all tiles past $1000, and therefore, the mappins get garbled up. I've noticed that the mappings that use tiles >$1000 wrap back to the start of the list; for example, if a sprite uses tile # $1010, it would corrupt and use tile $0010. Is this a SonMapEd bug/limitation or something else? I cant continue to edit knuckles art until this is problem is fixed...
It's a limitation of DPLCs (Dynamic Pattern Load Cues). You'll have to either overhaul the DPLC system or make Knuckles use less tiles.
Another way of doing it is the way they did for Sonic and Tails in S3&K -- split art between two files. Up to a frame you define, you use one art file; after that, you use another. You also have to modify Knuckles' DPLC routine to use this.
Thanks for the tips! I've decided just to delete some unneeded sprites to make more room for tiles (for Knuckle's, I deleted the twirling running sprites, used at the end of SSZ1/LRZ). I've been trying to port some music to S3&K using Music Pointer Fixer all day, but have been driven to insanity by failure. Specifically, I have been trying to port Green Grove Zone act 1 music (S3D) to AIZ1 to start with. After using MPF, I get something that is close to the original, but no cigar; the DAC and PSG work fine, but there are no FM instruments. I'm not exactly sure what I am supposed to be inputting into MPF to get proper results (raw pointers, absolute addresses, or something else?). Therefore, below I have made a picture of my inputs for MPF. I also pasted the offsets for the music, as according to the Music Hacking guide. Please point out my mistakes. ------------------ Offsets: S3D - GGZ1 Base offset$=$C0000 Pointer=$2480 (remember to convert to little endian!) Result=$C0024 S3K - AIZ1 Base offset$=$2C8000 Pointer=$8000 Result=$2C0008 -------------- MPF inputs: -------------- Also, here is the steps for manual porting according to the Music Hacking guide, for reference: Much thanks in advance!
