Personally though, I'd say collecting data offsets and the pointers they'd need to support the other version and handing them off to the programs' creators would be the best way to avoid terrifying headaches. You can also do some test edits in the program and apply the patch to the output ROM to test if this route will work at all. These are compressed by default, but the size of the patch relative to your ROM size should give you a good idea of how updatable the code base is. This type of patch accounts for moved data, so only code that changed or was amended/deleted should be affected. In order to test things you can make a differential patch using 1.1 and 1.0 ROMs. Bags are always filled with 75 of all items. This ROM hack enforces certain rules into the game itself. An Ironémon is a set of self-imposed rules designed to make the pokemon games more challenging. It's like walking into a minefield answering a question like that without a lot of reference. All 386 Pokémon are available and legal, with a few shinies. This is a Rom hack of the Ironémon challenge created by Iateyourpie. That, sadly, is a game-by-game, revision-by-revision subject. There's no guarantee registers and address space didn't wildly change between revisions. I would think altering resources only would be relatively safe, but it's hardly a guarantee.
It would take somebody familiar with internal code changes and what structures are being accessed by the programs to determine how you'd go about tinkering with things.
You haven't gotten a response mostly because it isn't an easy problem to explain.
0 kommentar(er)
