https://forums.sonicretro.org/index.php?showtopic=10880 So you know, this might be something that goes in the Basic Questions and Answers Thread. Just a word of advice. EDIT: And it's magically found its way here!
I messed with both of those numbers more times than I can count, and nothing has seemed to actually help. The best that I've been able to fathom is that for some reason, the branches aren't working as intended, so the code there is always checking on one side for a wall.
This really doesn't say enough... what is the error it's reporting? check the error.txt, or whatever the equivalent file is... and we can begin to help from there. After that, what is your hack doing? Does the spindash operate properly? Also... if you are following any guides here and using the old 2005 disasm... that's an easy path to a hard time. I'm not gonna lecture you about updating your shit... but I will say to be VERY careful of what you copy/paste into your outdated disasm. You can work with the old stuff, but it needs care. ANYWAY, errors... what have you?
The error is right there, you just have to actually read what it's saying. At line 6094 of your sonic1.asm file, you have a branch instruction pointing at an address which is out of range of the branch instruction. Now, you probably didn't touch this line at all, but what you did was add enough code between the branch and its target address that pushed the target beyond the maximum range. When this happens, you have to go in and manually promote that branch instruction to a wider range, such as bumping a short branch (.s) to a word branch (.w) In this case, given that the distance between the branch and the target is 32788 bytes (also seen in your error message), it's likely that your branch already started out as a .w branch and you just pushed the target address a couple of bytes outside of its comfort zone. You have a couple of options. If the branch is an unconditional branch (bra.w) or a branch to subroutine (bsr.w), you can just promote it to the corresponding unconditional jump (jmp) or jump to subroutine (jsr) instruction. If it's a conditional branch, then you have a bigger problem, because you need to somehow retain the conditional property of the branch instruction and jump to a far away location as well. In this situation, I would just place the custom code somewhere other than between the branch instruction and its target, and just have the original code jump there and then return. It's unusual for the target of a conditional branch to be that far away though, so I wouldn't worry about it. Also, next time please don't post screenshots of your entire desktop. Just the error message will do.
I want to swap Classic Sonic's model out with Shadow's, but I have no proper way to do so. Can someone show me how to do this, or just link me to a thread so I won't waste time making another?
So what do people use for Genesis music these days? Is FMDrive used a lot by people here? I definitely prefer being able to use a VST with a piano roll in FL Studio rather than being constrained to a tracker set-up. I have the impression a lot of people just use MIDI2SMPS, but making music you intend for the Genesis by first hearing it only with midi instruments or whatever seems like it would hinder the process in even knowing how to express with FM. Is this really what most hacks are using? Been waiting to hear more about MarkeyJester's dual PCM engine too, hopefully something that's not tracker exclusive
So, newbie question - are questions about non-sonic rom hacking ok in this forum? Or are those best in the other Technical Discussion forum? I'm attempting a rom hack of Gunstar Heroes and there doesn't seem to be much of a still-active community around MD rom hacking outside of this forum (that I've found at least). Thanks.
That would indeed better suited for the Technical Discussion subforum. The fact that it says "non-Sonic ROM hacking" in its very description should have been a clue :U Other games have been discussed there in the past, I researched a few myself.
I'm trying to replace the boss music for the Metal Sonic boss with the Metallic Madness Act 2 soundtrack from Mania. Metallic Madness is 1:14 long. I made my intro track 9 seconds, and the loop track 1:13. I used ADX encoder to convert the waves to ADX, then use SFIV to put them into an AAX file. But When I play the file, it shows up as 2:39. It's like it duplicated the track and extended it. I don't why it's doing this. Any help?
Um, that sounds like you have the player configured to loop the track twice and fade out for four seconds.
Hi! I would like to know... If there's the possibility to change the sprites of a ROM... Is it possible to change the sprites of a Mega CD BIOS? I only would like to change the background, the logos and if it would be possible, the music, but I don't find any source talking about it... Any idea, please?
Of course its possible! But, its not gonna be easy. Specifically, you will have to disassemble the code, to determine what is code, what is data, what are the graphics, their compression, etc... The worst thing though; If your art changes make the files bigger, you will have to relocate them somewhere, find all the pointers, fix them... Sure, if you are technically proficient enough, have enough time, and motivation, go for it, but personally I do not believe it is worth the effort. If you do however, you will have... "Buy" a copy for IDA, or some other disassembling tool, have a crack at disassembling code, and using it to find each section of data, check out the format, and extract the data files from the ROM into data files, open up with an art editing program or something, and see if its indeed art or not. This is something most people could not help you with, and many who could, wouldn't bother. Your time might be better spent learning the basics of Motorola 68000 assembly, and the Mega Drive features, before trying to work this out. There are few people who I know have worked with the BIOS before, and they may be able to help you, but these people are busy nowadays, so I wouldnt count on it either.
Lol I thought it would be much easier, like changing sprites in the games... Then it's a no for me. D: Thanks for your good explanation.
The reason why it's so easy to edit sprites in the Sonic games is because someone already found all the data and made tools to split it from the ROM and build a new ROM out of it. Nobody's done that for the BIOS yet. At least not publicly.
not sure if this is the place to ask it, but since I'm curious how to sonic 2's special stages work? (and how does the 2013 remaster make it better? do they just use 3d meshes?) I'm curious since there are a few editors for sonic 1, CD and 3's special stages but almost none for sonic 2
There are two different parts to S2 special stages: the half-pipe and the sprites. Sprites have graphics for several drawing distances, and they have two coordinates: distance (from "infinity") and angle. Distance and angle, with additional data from the track, determine on-screen X and Y positions*, which version of the graphics to use, occlusion by the track, collisions with characters, etc. The distance from infinity increases 4 units every 5 frames (using 16-bit fixed point fractions). This does not count the 4 lag frames caused by the track drawing routines; including those, sprites approach by 4 units every 9 frames. * except for jumping characters, which compute X and Y from normal equations of motion until they land. The track is a lot more complicated. It is prerendered, converted into discrete "frames", and compressed into a rather complicated compression format that is terribly slow to decompress: each frame takes 4 frames to decompress, interspersed with 5 game logic update frames. In order to achieve the frame rate it has, the special stage uses a VRAM double-buffer: the current frame is displayed for the 9 frames it takes to decompress the next frame. The track frames are actually compressed 128x32 plane mappings. The track tiles are already in VRAM, and consist of a single line repeated 8 times. When the special stage starts, a horizontal scroll table is set so that the first two lines of each drawn tile come from the first 32 tiles of a tile row; the next two lines come from the next 32 tiles; and so on. Then, there is a lot of geometry data I haven't fully decoded yet, which is used for positioning objects. The 2013 remaster just uses 3D to render stuff. If you have more questions, I can happily answer; just try to narrow it down more by what you are interested in knowing. For example, I assumed you meant about how they are rendered in this reply.
Apologies for the bother, but I have a question. I am hacking the Sonic 2 Simon Wai proto and the object and ring placements don't save in Casino Night and Wood. Could you please explain how to fix this? I am using SonED2. My disassembly is the Super Egg disassembly.
