twix, on Oct 23 2006, 08:39 PM, said:
fuck that, knuckles has different paths in the game so I don't know how you're going to tackle that one, I'd reccomend hacking sonic 2 for your first hack as it is much easier and theres more info on sonic 2, not to mention the disassemblies.
The idea behind the hack is to make sort of a puzzle game using the S3K engine. The way to advance won't be obvious, and will rely on specific character abilitites.
Problem is, if we make a puzzle designed for Sonic, Tails will just be able to fly over the damn thing, and Knuckles might not be able to jump high enough to get through at all. But if we restrict the player to just one character, we cut down
greatly on the amount of variety we can use.
Hence mid-level character swap.
For the same reason, using Sonic 2 doesn't really work, unless we want to port Tails w/ flight, and shield actions, for our first hack. Seems like that would be even more work than hacking S3K.
ThunderSpeed, on Oct 23 2006, 08:30 PM, said:
Hmm.... While I haven't looked deeply into Sonic3K's character handling code, I do know that Sonic, Tails, and Knuckles are entirely seperate objects. This means that in order for this to work, you would have to "create" an object containing your character of choice, then "delete" the one that's already there. However, this would probably lead to MASSIVE errors in the game code.
Not to mention, you'd need to load the character palettes, art, mappings, and such. In short: I don't think anyone has the balls to try it. =P
* NOTE: This post is pure speculation that I pulled outta my ass, so anyone with more knowledge on S3K, please correct me.
This is why I asked where the code is that runs when the player restarts a level. (But not during act changes).
Fooling around with pro action replay codes in Gens, I can change the player-character number on the fly. Interestingly enough, changes to the player number take effect whenever the "restart level from checkpoint" code is called. Whether it's from death, or from entering and leaving a bonus stage.
As a dirty work around, we could make the monitor set a checkpoint, change the character number, restart from checkpoint, and then clear the checkpoint.
More ideally, though, we could copy the code that runs when the level restarts (As it already does everything we need), and remove the "lock player control", "show title card", "reset time", "reset position" and "unlock player control" parts, then use what remains as the bulk of the monitor code.
ThunderSpeed, on Oct 23 2006, 08:30 PM, said:
Quote
What pointer tables would to be invalidated by adding a monitor item type, and where are they?
Where in the rom are the monitor item routines stored?
Is the last checkpoint you hit stored by Checkpoint #, or by X/Y location?
What RAM addresses hold the checkpoint values?
Where in the rom is the routine that gets called when you restart the level (from a checkpoint or otherwise)?
Can the checkpoint restart routines be called without decrementing the life counter as a result?
1. I don't think any pointer tables would be "invalidated", as, if the monitor types work like the do in S1 and S2, the effect is based on the animation. So if you wanted to add a monitor, you would need to extend the offset table of the monitor animations, add new mappings/art etc.
2. The monitor item routine data itself... I don't remember where they were. I was messing with them a while ago through hex, but I failed to take down any locations.
3. The last checkpoint you hit is stored by a checkpoint counter. That is why if you skip ahead through the level, hit a starpost, and then go back to another one, that one is active.
4. I haven't looked into this one.
5. Again, I haven't looked. But if this works a bit like Sonic 1 and 2, there are a few locations that are called when you restart the level.
6. I would assume so, with some minor recoding of the restart routines.
1. I read somewhere that the monitor data format changed between Sonic 2 and Sonic 3, so that might no longer be the case. The question about pointer tables was kind of assuming that there's no buffer after the end of the monitor data before the next data block begins, or that there's not enough of a buffer to add all the routines. Hence causing movement of the next block of data (and possibly any block after that...)
2. How did you find it originally? I'd look for this tuff myself, but I really don't know how or where to start.
3. I know that this behavior is true for Sonic 2. I'm not sure if it's the same for sonic 3 and later.
4. I can probably find it myself, but I thought I'd see if someone already knew.
5. Well, if I knew the common techniques to find instruction offsets, I'd search for this myself. But the only place I can think to start would be modifying each byte in hex, one by one, and testing what changes. In a 4 mb file, that could take more than a year.
6. Yeah, it occured to me that this is exactly what happens when you exit a bonus stage.
EDIT: For some of you other questions...
ThunderSpeed, on Oct 23 2006, 08:30 PM, said:
Quote
Where in the rom is the routine for the Debug monitor stored?
Where is the routine which checks for emeralds before calling transformation sequences?
Does this run before, or after, the 50 ring check?
Could it easily be made to kill the player on test failure
1. The debug monitor is actually one of the monitor types, but as I said before, I didn't take down any locations, so can't help you there.
3 and 4. I found this somewhere in the rom. However, when I was haxing, I didn't take note of the locations. And, for your second question: The emerald check happens AFTER the 50 ring check.
5. I would assume so, but you would have to edit the 'double jump' code to not make it so that Sonic/Tails/Knux would die if they became Super.
1. I know the debug monitor is one of the monitor types. And, presumably, if I new where monitor data/code was stored, I could find this just by its object sub-type. But I don't know its sub-type.
3. Yeah, I'll have to look for this myself. But any tips on how to do so would be appreciated.
4. Awesome. That means, we can have the monitor call the transformation routine, and only give say, 2 rings.
5. Actually, probably the better way would be to make it do damage if the check fails. There's going to be a minimum of rings in this, so if you're hitting one of the debug monitors, you'll probably just die.
ThunderSpeed, on Oct 23 2006, 08:30 PM, said:
I think that answers all of your questions. I'll say this though: Not much is known about S3K, so you're practically walking into the frontier of hacking. Also, if you plan to disassemble S3K, I hope you have a LOT of free time on your hands, as disassembling something like Sonic 1 would take possible months. Sonic 1 is 512 KB, and S3K is 4096 KB... I could only imagine how much time it would take. =P
Well, I was planning on using one of those programs that automatically disassembles roms. Rather than doing it by hand, so it shouldn't take months, or even hours. Documenting all the code, though, probably would.
Posted 23 October 2006 - 04:43 AM
