Language…
16 users online:  Ahrion,  AmperSam,  Ayami, bucketofwetsocks, Dispace, Green, Guido_Keller, Hayashi Neru, JezJitzu, Metal-Yoshi94, pnaha, ShadowMistressYuko, signature_steve, Sweetdude, Tomi P, Znes.609 - Guests: 246 - Bots: 279
Users: 64,795 (2,377 active)
Latest user: mathew

How to create a PPF Patch or a BPS Patch

  • Pages:
  • 1
  • 2
How to create a PPF and BPS Patch (BPS is recommended)

Sections:
PPF
BPS

Special:
Why BPS is better than PPF

PPF (Rating: Okay, but mostly used) return
Subsections:
How to apply a PPF Patch?
How to create a PPF Patch?

Some, who work on their own hacks, have been probably wondering how to 'create' patches. Well, first off. PPF is a good patching format, however I really wish (in my opinion) for a better patching format. But as this doesn't exist yet, we shall use PPF as it's pretty good for SM64 Hacks.

PPF stands for, as a handful people may know already, for PlayStation Patch File and was originally made in 1999 by a cracking group to distribute patches which bypass copy protections on PlayStation games. It was also used sooner or later for legal purposes, as it turned out to be a quite good patching format. Even early ROM Hackers used PPF Patches (before the Lunar IPS Patching Tool came out) before to distribute their hacks and modifications without releasing the whole game dump on the internet. Later, with the introduction of IPS Patching, PPF felt in the background (actually it never got that much popularity anyway except the PlayStation Hackers). In the early stages of SM64 Hacking (incl. N64 Hacking) IPS patches were still used, until someone (I believe it was VL-Tone himself) discovered the PPF Format, which allowed to patch bigger files. (You can look in the Acmln Board Archives to look how SM64 Hacking Development went and how it reached what it is today)

How to create a PPF Patch?
Now, after we got through the historical part, how do I create a PPF Patch? You might know already (from the sticky) how to patch a PPF file to a clean ROM, but how do we now create one? For this, we're going to need following tool:

- PPF-Studio 1.01b (lastest release) : http://www.romhacking.net/utilities/514/

And we need of course TWO ROMs:
- An unmodified ROM (same ROM, just unmodified) (make a backup)
- The ROM you're going to modify



What we have to keep in mind is, that our ROM haves to be equal the filesize. For example, if our ROM was extended to 24MB and expanded to 65MB (Level Importer) we're not able to create a patch from the original SM64 File (8MB) with the extended/modified SM64 ROM(65MB). It will error in PPF Studio. Instead we could use an unmodified/clean extended SM64 ROM(65MB) with a modified extended SM64ROM(65MB). For example, we're going to change the header "SUPER MARIO 64" in the ROM, which you may have seen already when you open up PJ64 with the SM64 ROM seeing the title saying "SUPER MARIO 64" which basically is reading the header of the ROM and displaying it in the window title of PJ64.

Now, please create a backup of your unmodified SM64 ROM, as we later need it. Open the SM64 ROM with any Hex Editor you may like. (I use Cygnus Hex Editor) And edit the header:



We edit "SUPER MARIO 64" to something like: "SONIC IS FAT"



Now save it and try if it works. If everything went right, your ROM should start manually and the window title should show now: "SONIC IS FAT".



Okay, everything worked, no bugs, no errors, so we can now start and create our PPF Patch.

Open up PPF-Studio. First, we're going to open up the PPF File (Output) path, that's where our PPF File is saved once it's created.
I call it SM64TestPatch.ppf (remember that you also put the .ppf extension to it! PPF-Studio does not do this automatically)



"Öffnen" means "Open..." btw. However, don't worry about that. It's basically nothing else than "save" in this case, as the PPF File is being created ONCE you pressed open. Difference here is, that PPF-Studio writes the PPF file "live" (aka file input stream) and therefore it's not readable while PPF-Studio is not done creating the patch. (Just saying) So once we're done creating the patch and PPF-Studio says so, the so-called file stream is over and the patch can be opened.

Under Patch Description you write in short what your patch does, respectively what you're going to get once you applied this patch to the ROM. File_id.diz is basically the very same, and comes from the old bulletion boards. DIZ just means: Description in ZIP and does like "Patch Description" explain what the patch does, how it works, etc. I put the details into file_id.diz but not too much, as the PPF Filesize increases with this too. The file_id.diz is getting included directly into the PPF but is also ignored by the PPF Patcher (PPF-O-MATIC) and you don't have to worry about that something may go wrong. But, you should prevent using "unusual" ASCII characters as this could really mess up the patch somehow.

You can also, if you want use the so-called: "Include Undo Data" patch function. It allows you to undo a patch, once you've patched it into a ROM. I'm going to explain this later, as a "Bonus".

Now let's finally create our patch. We have to look into Group "PPF Creation Control" and select "General" as this is a general patch. It now asks us for two files, the original and the patched file. Yes, that's why I told you that we need the two ROMs. For original file, you select the unmodified and clean ROM file, and for the patched file you select the modified ROM file where we have edited the header to "SONIC IS FAT".



Another note:
Quote
Remember. The ROM filesize has to be equal. For example, we could've edited the exact same thing, the header for example to "SONIC IS FAT" in a 65MB ROM. However, we can't select the very, original 8MB or 24MB SM64 ROM for original file. Instead you need to make a backup of your unmodified 65MB ROM, then modify the SM64 ROM which is 65MB big and later use backup 65MB ROM for Original File


Once you're done, press now "Create PPF-Patch"



"Ready. Found 2 differences."

The patch is done. Now, the consumer can go on and do the usual routine process:

1. Open up PPF-O-MATIC.
2. Get a clean SM64 ROM (mine is 65MB big, so the user would need a fresh and clean extended+expanded ROM (65MB) too)
3. For ISO File, Select all files and press on the clean SM64 ROM.
4. For PPF Patch, user selects the provided PPF File.
5. Now the user press "Apply" Button and the patch is applied to the fresh ROM.
6. Done!



Additional/Helpful Information:
Now to a special part. Let's say you are working on a ROM Hack, you needed a patch like GSCI by Kazeshin and now your ROM is dead, no backup, nothing. A disaster. An undo-patch function would be quite nice and could actually save your work. And PPF does, luckily, support this. Now you just need to enable (next time you do a PPF Patch) the "Include Undo Data" checkbox in PPF-Studio.



Now, create the patch as usually and patch it to the clean ROM. Now, you want to undo it, right? Open up PPF-O-MATIC, select ROM and PPF again and this time check the "Apply Undo-Patch Data"



Now, just press "Apply" Button like usually and you notice how the patch is completely gone from your ROM and it's reverted back to the state before the patch was applied. This can be really useful and save your work which you could've been working months on.

BPS (Rating: Perfect) return
Subsections:
How to apply a BPS Patch?
How to create a BPS Patch?

BPS is another patching method, which turns out to be better as PPF. This will be explained here, in short:

Advantages:
- Users won't need to extend+expand their SM64 ROM anymore. They simply can take their 8MB SM64 ROM and apply the patch(made with 8MB(Original File) and 65MB ROM (Modified File) ) to it and the ROM is already extended+expanded successfully and you just need to play it now in PJ64.
- BPS creates incredibly small patches. Original File, normal SM64 ROM: 8MB, Modified File(Levels, Patches, etc.): 65MB. The patch filesize turned out to be just 3MB! And this patch will turn your 8MB ROM into a 65MB ROM!
- (Not directly related to BPS) Flips (Floating IPS) is a very user-friendly tool to apply and create BPS patches. It looks more organized, so that even the dumbest person (no offense, really) on earth could use this thing.

Disadvantages:
- Creating the BPS patch can take a bit. For me it took around 2 minutes for the SM64 (65MB) ROM. But I think, that 2-5 minutes aren't really that much to wait. Of course, you also can take "BPS (Favor Creation Speed" which will improve creation speed but the result may be larger as if it's done with "BPS (Favor Small Size)".

How to apply a BPS Patch? return
First off, you need this tool:
http://www.smwcentral.net/?p=section&a=details&id=10347
This is Flips (short for: Floating IPS) which allows to create/apply IPS and BPS patches. Of course, we need BPS.

Now, start up the tool:

(Wow, so tiny and just that perfect)

Instinctive, you might already know already what to click. It's really simple as said before. Press "Apply Patch":

(Vocabulary: Öffnen = Open, Abbrechen = Cancel, Dateiname = Filename)
Once the patch is selected, another window will open, asking you for the clean, unmodified and original ROM. Select "All Files" first in the menu, as "Most Common ROM Files" seems not showing ".z64" extensions.



Select it. Now (last time) another window will open, which basically asks you if you want to save the patched SM64 ROM under a new name. (Default name which is shown is the name of the patch, in this case SM64TestPatch) You can overwrite the original, of course. But in case you want to keep the original, better save it like it is or use an own name for it.


(Speichern = Save)

After you're done with this, you should get the new file (which is 65MB big) and a message showing that the patch was successfuly applied:


The result:


How to create a BPS Patch? return

Now, we're going to show how to create a BPS Patch. It's really simple. Open up FLIPS and press "Create Patch". A window opens. The window title says it already: "Select ORIGINAL UNMODIFIED File to Use" which is Original_SM64.z64 in our case.



Now, another window opens and (obviously) this time you need to select the modified SM64 ROM. (In our case, the SM64TestPatch.z64)



Now another (last time) window opens and this time you need to give your patch a name and obviously what kind of patch you want to do. In our case, we'll use BPS. However, there are two options.



If you want to create your BPS Patch as fastly as possible, you'll take the favor creation speed. If you want the favor small size of your BPS, you will need to wait a bit longer, but the result is astonishing. (The waiting time isn't really that long. But that may depend on every CPU)

Once it's done and no errors occured, it will show you this:


And again, the result:


Look how small it is. That's really astonishing.

Why BPS is better than PPF return

BPS is extremely better if we talk about filesize and usage. While you had to extend+expand your SM64 ROM to apply the PPF patch, the BPS patch can be simply applied already to a clean 8MB SM64 ROM.

- Users won't need to extend+expand their SM64 ROM anymore. They simply can take their 8MB SM64 ROM and apply the patch(made with 8MB(Original File) and 65MB ROM (Modified File) ) to it and the ROM is already extended+expanded successfully and you just need to play it now in PJ64.
- BPS creates incredibly small patches. Original File, normal SM64 ROM: 8MB, Modified File(Levels, Patches, etc.): 65MB. The patch filesize turned out to be just(if you used "favor small size" option) 3MB! And this patch will turn your 8MB ROM into a 65MB ROM!

As descriptive as an actual video, I always felt this forum was missing something, I hope this eventually gets stickied.
Will one find the file_id.diz useful when creating SM64 patches or just for Playstation ISO(s)? I mean how do you view the information?
Originally posted by Cackletta
As descriptive as an actual video, I always felt this forum was missing something, I hope this eventually gets stickied.


Thank you.

Originally posted by Wario man21
Will one find the file_id.diz useful when creating SM64 patches or just for Playstation ISO(s)? I mean how do you view the information?

Yes, it's shown once you open the PPF File in PPF-O-MATIC:



You can also view the file_id.diz inside the PPF File if you open it in Notepad.

For the "useful" part:
That really depends. For me and for others it may be useful for details, but that easily could be also put into a separate README textfile. Another disadvantage of file_id.diz would be that the filesize of the PPF increases. That's why you usually should put all important stuff and details of what the patch exactly changes (addresses, values, etc.) into a separate textfile and put it later together into a ZIP.

Actually it should be enough if you shortly describe what the patch is going to give you in "Patch Description".

Originally posted by Tarek701
Originally posted by Cackletta
As descriptive as an actual video, I always felt this forum was missing something, I hope this eventually gets stickied.


Thank you.

Originally posted by Wario man21
Will one find the file_id.diz useful when creating SM64 patches or just for Playstation ISO(s)? I mean how do you view the information?

Yes, it's shown once you open the PPF File in PPF-O-MATIC:



You can also view the file_id.diz inside the PPF File if you open it in Notepad.

For the "useful" part:
That really depends. For me and for others it may be useful for details, but that easily could be also put into a separate README textfile.

Actually it should be enough if you shortly describe what the patch is going to give you in "Patch Description".

Also, I'm really disturbed, after Cackletta modified my ROM it was 66MB and I'm not sure if patching will work since it isn't the same size, is there a way to get around this?
Originally posted by Wario man21
Also, I'm really disturbed, after Cackletta modified my ROM it was 66MB and I'm not sure if patching will work since it isn't the same size, is there a away to get around this?


If your backup/original ROM is about 65MB big and the modified one is 66MB big, that should work (I believe). Try it out.

It just shouldn't be like this:
Original File - 8MB
Modified File - 65MB.

Cause that's not gonna work for creating patches. I tried that. It will error you with "Files are not equal in size" in PPF-Studio.

Originally posted by Tarek701
Originally posted by Wario man21
Also, I'm really disturbed, after Cackletta modified my ROM it was 66MB and I'm not sure if patching will work since it isn't the same size, is there a away to get around this?


If your backup/original ROM is about 65MB big and the modified one is 66MB big, that should work (I believe). Try it out.

It just shouldn't be like this:
Original File - 8MB
Modified File - 65MB.

Cause that's not gonna work for creating patches. I tried that. It will error you with "Files are not equal in size" in PPF-Studio.

So, PPF studio approximates file size? With lunar IPS, even if there is a 1kb difference, it won't work.
Originally posted by Wario man21
So, PPF studio approximates file size? With lunar IPS, even if there is a 1kb difference, it won't work.


There is a limit for patching PPF Files (maybe). As I said, if the difference is too huge for both Original File and Modified file, it's not going to work. I tried it with both clean ROMs. The one being the one dumped in 2000, the 8MB SM64 ROM and the extended+expanded one (65MB). Obviously, PPF-Studio did not create a patch of it. So, there's either a limit to this or it's something else.

That's why I also said at the beginning that I wish for another patching format, a better one.

To Lunar IPS:

Quote
Has support for patching files up to 16 MB in size, which is the limit of the IPS format. The files can technically be larger than that, but the IPS format cannot record changes beyond the 16 MB mark due to 24-bit addressing. The IPS file itself can be any size.


1KB difference would actually work.

What about .bps files, which FLIPS can make and patch?
Originally posted by MercuryPenny
What about .bps files, which FLIPS can make and patch?


Well, I just tried FLIPS v1.12 with 8MB(Unmodified) and 65MB(Modified) and it turned out really good. The patch is just 3MB big. Disadvantage is just, that it takes a while until the patch is finally created. But the filesize of the patch is really small and the applying the patch is very fast. (To me)

That's a really good choice in my opinion.

EDIT:
Well, I decided to use BPS Patching in future.

Advantages:
- People don't have to extend and expand the ROM anymore. You easily could use 8MB (unmodified, complete original dump from 2000) with 65MB (modified) ROM and create a 3MB Patch. People just need to apply it over their 8MB ROM. The rest is completely done by the tool.
- It's damn small, even with 65MB filesize, the patch turns out to be around 3MB. That's epic shit we got here.
- It can be easily created, very user-friendly. Just use FLIPS v1.12, click "Create Patch", select original file, then modified file. Done! Applying patch is also very easy. Just click "Apply Patch", select the original ROM and apply the patch.
- Applying the patch seems really fast.

Disadvantages:
- Creating a big patch can take a little bit. It may depend if you have a good computer. My one took around 10 minutes to create the patch.

If more disadvantages, you may post them here.

BPS is a delta patcher, so it can detect insertions/deletions, and it can perform dictionary and run-length compression. Hence the format itself can produce patches that are very small, and will absolutely destroy IPS on insertions/deletions.

But it's really slow in this mode, because this is an NP-hard to NP-complete problem. None of us can find an algorithm that beats O(n^2) for delta-mode diff creation. We've used all the optimizations we are smart enough to come up with, but even our best doesn't hold a candle to what Xdelta and bsdiff are capable of in terms of patch creation speed. Although it does rival them in patch output size and patch application speed.

The main advantage of BPS is the format is super, super simple. A dozen times simpler than Xdelta. And once anyone figures out fast patching, no format change will be needed. The patch results will be even smaller, too. That and you can patch directories (multiple files), too.

So if anyone can understand this PDF => http://www.daemonology.net/papers/thesis.pdf , please get in touch =)
(This post assumes that you know that I also have an IPS/BPS patcher.)

Originally posted by byuu
and will absolutely destroy IPS on insertions/deletions

We're using PPF here.
But the differences are small; IPS can resize files and has single-byte RLE support, while PPF has 64bit offsets, so your arguments still apply.

Quote
And once anyone figures out fast patching, no format change will be needed. The patch results will be even smaller, too.

If you mean that we can substantially shrink our BPSes, I don't think so. We can tweak the heuristics a little, but we're pretty much already trying all possible matches, so I don't think there are any major gains left.
If you mean that BPS is smaller than bsdiff and Xdelta, I can't oppose that statement, but I doubt its truth value is going to change either.

But faster, absolutely. I actually did make some kind of delta patcher by ripping out the suffix sorter from bsdiff.c and then using a specialized binary search; it takes about 11 seconds for those 64MB SM64 ROMs (0.6s for a 4MB SMW ROM), while I get five to six minutes on the old algorithm (four seconds for the 4MB file).

But due to the TargetCopy dictionary size not being constant, I couldn't figure out how to use it there, so the output size is roughly the same as on linear patches (it's surprisingly close, actually).

This patch creator never got released; it's neither faster nor smaller than the alternatives (I heard Xdelta takes about one second for the SM64 ROMs, on a likely worse CPU), and I can't understand what it does, so I'm probably just going to trash it.


An example of a heuristics tweak: If there are multiple length-5 matches and no length-6 or higher, you pick the one earliest in the input, while I pick the one closest to the Source/TargetCopy pointers. This reduces the encoded numbers and thereby their size, which shrinks the entire patch. I don't remember exactly how much better it is, but I'd guess about half a percent on the entire patch. I think the speed impact was neglible.
I also made some tweaks to which encoding is chosen; if memory serves, I'm more eager to use TargetRead if the previous byte was TargetRead than if it wasn't. (Can't remember the exact thresholds I used.)

(On a somewhat semi-unrelated note, you did fix that lockup during patch creation, right? Leaving the program completely unresponsive while it's working is rather disorienting; the user won't know what's going on. My solution is to toss a callback back to the UI into the patch generator, works well enough.)
<blm> zsnes users are the flatearthers of emulation
Originally posted by byuu

So if anyone can understand this PDF => http://www.daemonology.net/papers/thesis.pdf , please get in touch =)


Oh boy. Xdelta is really complicated. My math skills are way too bad for this.

And thanks for stickying this, Alcaro.

To the patching formats:
Personally, I've decided to take BPS Patches for my baseroms instead of PPF. It seems better, easier and the users who download the baserom won't have to extend+expand the SM64 ROM theirself anymore. They simply could take the 8MB ROM, use the baserom patch and get the SM64 65MB ROM. And applying the patch is really fast and just took 2 secs for me.

This tutorial was made because most SM64 Hackers asked me a while ago how to create PPF Patches as they couldn't find it anywhere on this forum. So I quickly made this tutorial for them.

> If you mean that we can substantially shrink our BPSes, I don't think so. We can tweak the heuristics a little, but we're pretty much already trying all possible matches, so I don't think there are any major gains left.

Forgive me if I've forgotten some of the details. But last I recall, I only checked on 8-byte boundaries to speed things up (may have been obsoleted by the 16-bit hash+list setup), and it's also really quite challenging to ensure when it's smarter to encode raw data or a relative pointer due to the variadic integer sizes, well, varying.

I know that Screwtape's patcher managed to beat mine in a few cases, so mine isn't fully optimal at least. Yours may well be, in which case, yeah. I will concede that Xdelta -9 is fierce, and tough to beat.

> This patch creator never got released; it's neither faster nor smaller than the alternatives (I heard Xdelta takes about one second for the SM64 ROMs, on a likely worse CPU), and I can't understand what it does, so I'm probably just going to trash it.

All the same, please accept my sincerest thanks for your efforts on this problem.

> On a somewhat semi-unrelated note, you did fix that lockup during patch creation, right? Leaving the program completely unresponsive while it's working is rather disorienting; the user won't know what's going on. My solution is to toss a callback back to the UI into the patch generator, works well enough.

I've been on an extended hiatus as of late. Slowly but steadily building up steam, going to take me a while to back to daily full-time coding again.

I did add std::thread support to keep the UI responsive, but there is a regression crashing things in multi-file (BPM) mode.
Quote
Forgive me if I've forgotten some of the details. But last I recall, I only checked on 8-byte boundaries to speed things up (may have been obsoleted by the 16-bit hash+list setup),

I don't recall seeing any eight-byte boundaries when translating your code to C; there may have been a two-byte skip somewhere, but nothing larger than that.

There are some small gains left, yes, but nothing massive; we can probably gain about 6%, but that's it. Okay, maybe 6% does count as massive, depends on how you count.
For example, here's what's in front of a code to append the target tree on every byte, not just where I begin a block:
Originally posted by my code
//adding this here cuts speed in a sixth and size to 97% - not worth it

(It's pretty much the same principle as your eight-byte boundaries.)

...hey, your webpage says that if we can get 6%, we'll beat Xdelta! Okay, it is massive then.
(Your page also says that a BPS patcher in 20 lines is possible, but your own patcher is 86 lines not counting the crc32 calculator. BPS is a beautiful combination of power and simplicity, but no patching format I know of goes all the way down to 20.)

Quote
and it's also really quite challenging to ensure when it's smarter to encode raw data or a relative pointer due to the variadic integer sizes, well, varying

Doesn't sound too hard to me; shouldn't be harder than if ((distance<=0x80/2 && sourceCopyLen>=3) || (distance<=0x80*0x80/2 && sourceCopyLen>=4) || sourceCopyLen>=5).
Finding the optimal numbers could take a while, but that's more boring than "really quite challenging".

...okay, maybe it's harder than it sounds. I didn't try it.
I probably should.

Quote
I've been on an extended hiatus as of late.

That explains where bsnes 095 went.
Whatever, I'm not in any hurry.

Quote
I did add std::thread support to keep the UI responsive

Well, that works too. I've done a bit of threading work, it can get quite nasty if you're not careful...


I also poked the source code of Xdelta a little; according to the comments at the top, Xdelta mentions some kind of hashing, while bsdiff has its suffix sorting. Either method should be fine for our purposes... if we can figure them out...

Maybe the best way to create a BPS is to take one of these and making it emit BPS instead of the Xdelta format (seemingly known as VCDIFF).
Judging by the C# thingy I found at Wikipedia (the others were far tougher to figure out), VCDIFF seems to be based on the same ideas as BPS. Your interpretation is simpler, but VCDIFF seems faster to handle and looks like it could compress better; for example, it seems to separate their equivalent of TargetRead from the instruction stream.
In fact, you're even using almost the same integer encoding scheme! The 0x80 bit is inverted, and you use little endian while VC uses big endian, but the principles are the same.

Hm. Maybe the best method is just using VCDIFF directly. Who knows?


(sorry for the derailment, SM64 guys; it's not often byuu wants to talk about patches, and I don't want to miss it.)
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro

(sorry for the derailment, SM64 guys; it's not often byuu wants to talk about patches, and I don't want to miss it.)


Oh, don't worry about that. Look it from an optimistic side: We all will learn something from this conversation. You guys also motivated me.

EDIT:
Updated the topic and added div id's + added BPS Patching Tutorial and also how to create those.

I personally prefer xdelta, it automatically expands your 8MB SM64 ROM to 64MB.
Quote
Floating Lunar IPS

Sigh. Remind me to use a less mistake-prone name for my next tool.

Quote
"Most Common ROM Files" seems not showing ".z64" extensions

I'll fix that for Flips v1.13. Do you want .n64 too?

Originally posted by Cackletta
I personally prefer xdelta, it automatically expands your 8MB SM64 ROM to 64MB.

BPS does too.

Can't claim I know whether Xdelta is better than BPS, though. They seem pretty evenly matched.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro

Quote
"Most Common ROM Files" seems not showing ".z64" extensions

I'll fix that for Flips v1.13. Do you want .n64 too?

Yes, that sounds like a good idea. You could do the known N64 Extensions too, such like: ".v64", ".n64", ".z64" These three are pretty much the most upcoming extensions I've seen on N64 ROMs.

I actually wanted to do that myself, cause I found fastly enough the part where the extensions are called up. (under flips-gtk.c) Just add the file extensions line there:

Code
gtk_file_filter_add_pattern(filterRom, "*.n64");

etc.

Then re-compile and profit.

Of course, it's better if the original developer does this in case something may go wrong by an amateur like me. :D

> Your page also says that a BPS patcher in 20 lines is possible, but your own patcher is 86 lines not counting the crc32 calculator.

Yeah, it gets more involved when you actually validate all the checksums and count the variable-length integer functions as part of the size.

CRC32 though can be done in a single line, it's just way slower that way than with the computed tables. Have to do it one-bit at a time without the tables.

But compared to Xdelta's source ... it's substantially easier.

> Maybe the best way to create a BPS is to take one of these and making it emit BPS instead of the Xdelta format (seemingly known as VCDIFF).

Yeah, that may be best. It's not as important how much we cheat in creating the patches.

> Can't claim I know whether Xdelta is better than BPS, though. They seem pretty evenly matched.

BPS tends to compress better than regular Xdelta3. But if you use Xdelta3 -9, that performs some sort of compression inside of the patch, and Xdelta3 patches win on size. But if you then use BPS inside 7za -mx=9, you can beat it. But then if you do Xdelta3 -9 + 7za -mx=9, Xdelta comes out on top again.

We're talking about a difference of around 1-6%, depending on which step you're comparing.

So ultimately, if your criteria are fastest to *make* a patch, and smallest size, Xdelta wins, no contest.

If your criteria are easier to use application (beat or flips), much simpler format, and easier to embed into other programs (Xdelta is GPL, BPS is public domain), or the ability to create folder patches, BPS wins. Snes9X can never have Xdelta soft-patching, but it already has BPS soft-patching in v1.54.

If we improve BPS creation speed and compression strength, we can overtake Xdelta completely.
  • Pages:
  • 1
  • 2