[Gideon Zhi]

Also "Patching is changing one file (exact, down to the last byte) into another file (exact, down to the last byte)." is not strictly true. Plenty of games can be trimmed or have an existing patch applied. It might cause problems if they overlap or pointers get twiddled and render something else effectively not there but there are plenty of things that will work side by side, and with no way of predicting ahead of time (think hardpatching a game genie cheat in or something).

This is true, though at the very least a warning to the casual user should be displayed that what they're doing might not have the results they expect. Said warning is not something IPS can handle.

[Zoinkity]

If you want to dredge up an edge-case, one situation where you have valid, patchable dumps despite differences in the binaries are with rewritable formats like FDS and 64DD.  64DD, and likely many actual CD/etc disk dumps, also have system data that varies per-disk.

It would almost be worth extending BPS to occlude blocks of data to handle that situation.  Also be nice to explicitly get it to explicitly ignore files when generating a directory patch.

[Kallisto]

Why not combine all methods together into one package? Though I admit that would be pointless.

[freem]

there was a decent enough writeup about this in some NES game hack I found on the internet; I'm going to reproduce it here:

This is distributed as an xdelta patch and I already know everyone is saying "what the fuck is an xdelta patch"

basically since I did a few things, making an IPS patch of this hack is out of the question:
1) added more CHR-ROM
2) added more PRG-ROM
3) data/code has been shifted since I worked from a disassembly

As for patch formats, I tried using a few others:

• .rup (NINJA) came out to be 53.4KB (!! wtf)
• .ips came out to be 32.2KB (8.2KB bigger than original ROM)
• .bps came out to 30.3KB (6.3KB bigger than original ROM)
• .xdelta is only 12.1KB
• .bdf is even smaller (8.86KB), but asking people to use a command line patcher is out of the question lmao

I would imagine distributing a patch that is bigger than the source ROM itself is very pointless, when better options exist.

[FAST6191]

Bigger than the source ROM can vary depending upon what you are doing -- full voice acting injection is probably going to be bigger than the average game it goes into.
If you find some early docs and they speak of size concerns then it is not such an issue any more as bandwidth and storage have rendered it pointless for almost all we deal in around here. That said with some of the simpler formats it is a good indicator that you are probably distributing a whole ROM and that is a good reason to pause and reconsider.

With all that said if you have the option to make a smaller patch then it makes sense.

[henke37]

This is a difference in viewpoints. Is patching the process of applying a series of changes or is it a transformation from one specific file to another specific file?

[FAST6191]

Is writing a process for my shopping list or potentially life altering legal documents? Time was there might have been separate things for both but these days there is just the one for most things people like. There can be distinctions and stylistic choices (if we are going patches then the option to say ignore what the input file hash is) but why not both.

[mrrichard999]

Any chance of someone being able to create a program capable of creating a patch of all these types of formats and also gives the option to show which one would save the most space? There must be a genius coder around here capable of creating such a program! 

[FAST6191]

You could probably do it with a batch file if you wanted to (have the command line implementations of each patcher, have options to feed the original and patched ROM, have it generate the patches for each type and then list file sizes with names which is just a directory command).
The trouble would come with things like xdelta and bsdiff (the bdf thing from the link) which have some options you can set for compression, match length and search window sizes -- set some of those up into extremes and making windows the same size as the game and feed it a 500 meg DS game or several gig 360 game and it takes an age to generate a patch (I don't know if it is strictly exponential but you can easily send a hour to make a patch session into the days range), compared to rather more modest/stock settings. It is in this which you usually find the differences between xdelta and bsdiff arise when people compare them.
You also have things like the wii which did fully encrypted isos, hence the file system aware stuff some mentioned before.

[tvtoon]

there was a decent enough writeup about this in some NES game hack I found on the internet; I'm going to reproduce it here:

I would imagine distributing a patch that is bigger than the source ROM itself is very pointless, when better options exist.

Well, ranging by sizes is not the better approach. Xdelta is not some "alchemiracle" solution and its default behavior is to use compression (zlib) to complement its processing. So, to the common user, it may seems great at first but the game data is still there, massively input.

Just to take a note, I am totally against internal compression for patches.

[Gemini]

You can simply disable any compressions on xdelta, just select the compression level and set it to 0. As for game data still being there, it's not really when you set a large window buffer, which can easily drop size by a great magnitude.

[FAST6191]

What is the matter with internal compression? Sure I have been known to occasionally edit IPS raw and even instruct others to do it (half a screen of hex is apparently less scary than editing a ROM), it does not massively add to end user patching time and Gemini already took the original data still being there thing. I guess my external compression might be better and in the case of multiple patches then it might frustrate 7zip or something making a library from all files in the archive but that does not seem like a great reason.

[tvtoon]

What is the matter with internal compression? Sure I have been known to occasionally edit IPS raw and even instruct others to do it (half a screen of hex is apparently less scary than editing a ROM), it does not massively add to end user patching time and Gemini already took the original data still being there thing. I guess my external compression might be better and in the case of multiple patches then it might frustrate 7zip or something making a library from all files in the archive but that does not seem like a great reason.

There is your answer.

[jonk]

Hmm. Is this discussion moving towards the idea of a patch librarian and branching version control capability (amid other thoughts)?

[Pennywise]

I don't know if this has been brought up, but there's this patching program called Floating IPS that supports IPS and BPS among other formats. I think byuu recommended it to me when I was having trouble getting beat to work on my computer.

[Gemini]

I guess my external compression might be better and in the case of multiple patches then it might frustrate 7zip or something making a library from all files in the archive but that does not seem like a great reason.

I agree: compression ratio isn't a great reason. For what, after all, a bunch less MB for huge patches? Kinda reminds me of the ECM ISO format, which still pollutes the net with redundant converters, obnoxious expansions, and barely any real gain.

[resq]

First of all, I know I'm gonna get a lot of hate messages for this from people who think I'm a crotchety old hacker who can't accept change. I get that.

However, lately I am seeing all kinds of patching formats all over the site, and it's getting frustrating that I need a separate program to use each patch type, and some of them won't even patch at all if I don't have the exact same copy of the ROM right down to the byte. We've been using IPS since the 90's, and everything has been built to function with IPS patches.

ye I feel you. And what about people using the new 7-zip to compress files instead of WinRAR. It doesn't even do anything that's better. All it's doing it making me have to download the new 7-zip just to unpack it. Complete nonsense.

[Gemini]

Erm, WinRAR decompresses 7zip just fine.

[Lilinda]

Plus, 7zip, well, is old as hell as well, and also in most cases compresses better, often a fuckton better(If a game is heavy in CDDA style music tracks Winrar's better. Sega CD is very much the poster child for systems with games that always compress better with Winrar).

[FAST6191]

On 7zip it is free, does compression well and is available via Ninite. Likewise those using winrar can still decompress it and have been able to for years. Unless you need to make scene style archives or add new things to existing rar files there are no downsides to using it, no great reason to shift from winrar if you are happy with that either.

About the only thing it does not do is ACE files but if you have one of those then something has gone wrong, that and lzh but if you are dealing in those you probably know you are going to want something more dedicated anyway.

Back to the my external stuff might be better then at this point compression is more or a courtesy than a necessity, and about the only times I juice it are when trying to squeeze things just outside it into a 10 meg email limit.

Hmm. Is this discussion moving towards the idea of a patch librarian and branching version control capability (amid other thoughts)?

Normally I am all for feature creep, or "we are 90% of the way there"/story of GIT, like that but in this instance input file, output file, ignore input file hash are what I would go in for as far as required end user options, everything else being cosmetic/how much you want to thrash your equipment is what I would drag my heels for. I am all for version control being taken up by hackers, indeed I have seen several use GIT before now but I would want patching to stay its own thing.