ROM Hack How do I Patch AND trim a NDS rom?

[Hebon]

Title says it all. Is there a problem if I trim then add the patch?

 

[Auryn]

OR
if you have to ask how to patch the rom, you don't have the rights to play it.

 

[ivobhz]

It can be a problem if the patch tries to write data in the trimmed part of the rom. You should do the opposite, add the patch then trim.

 

[basher11]

usually patches trim the rom for you.
but as ivobhz said, trim after patching if it doesn't trim for you.

 

[Hebon]

The problem with trimming after I patch is that the trimmer seems to think that the size of the patch itself is how big the rom can be trimmed down to. For example; if I have a 64MB game and it can normally be trimmed down to 52, but I had applied a 1MB patch, the trimmer says it can be trimmed down to 1MB.

 

[shadowmanwkp]

If you patch a game, usually the patch maker has used junk bytes in the rom to make the patch. Because trimming removes those junk bytes, applying a patch afterwards will always fail, unless the patch maker has taken this into account. By modifying the rom, the header and other data will also be altered, thus if you trim afterwards, the trimming utility doesn't recognize the rom properly and it will result in a broken rom. Patch makers will usually trim the rom to the right size after making a patch, so you don't need to. If you really want to be certain that the game is trimmed, even though you've patched, you can open the rom up in a hex editor and remove all 00 or FF bytes at the end (do this at own risk though)

 

[FAST6191]

That might be true on the GBA shadowmanwkp and I can not speak for pokemon (of which most of the hacking work is done with premade tools) and some of the tool driven hacks (thinking the likes of the mario level editors) but most full blown hack projects will either inject files back into the rom in place (quite OK to trim), properly repoint the modded files (should still be OK), rebuild the rom (most rebuild tools tend not to add the stuff that is trimmed back in) and generate a patch for it or rebuild the rom as part of the patching process (again will likely not have anything worth trimming).

On the flip side some patching methods will add in any extra space if they need but it can also trouble some patching methods (no real idea why but it does) so theoretically you could come at it the other way and trim then patch. At all times you should be prepared to force the patching method to ignore and initial file difference (xdelta and bsdiff are pretty keen on this).

 

[Hebon]

If certain patchers also trim, does the xdelta patcher fall into that category?

 

[FAST6191]

Most hackers will find the files they want to edit, edit them accordingly and repack the rom before generating a patch to turn the original rom into the repacked rom (occasionally you get roms that do not like this and hacks that are just a few bytes being changed rather than added so the rebuilding part might change a bit but that does not really concern you as the end user unless you have a bad flash cart). This repacking stage is what does the trimming side of things if any is to be done.

xdelta and bsdiff are the two main methods to build patches for end user distribution with and they come from the general file patching world and as such they know nothing of DS roms (certain hacks like the Jump Ultimate Stars translation can work with the DS file system but again we are drifting back into actual hacking related issues)- they replace bytes that have changed and if you have shifted a part of the file around (as rom rebuilding tools are wont to do) they will try to match it up with the new location as well (one of the reasons we no longer use IPS for rom patching is that it can not do this) as well as remove anything from the file if it is not there any more. Naturally all this requires fairly extensive computing ability (somewhat analogous to compression) which is one of the reasons for having so many formats and why patches can end up quite large (they might fail to see a swap/shift and assume it is just a change and pack in the "change" accordingly) but this is getting off topic once more. The check thing stems from the general patching world so as to prevent people from applying the patch to the wrong backup or version of the file (rather than back everything up all the time most of these sorts of things were built to allow just the changes to be stored).