News:

11 March 2016 - Forum Rules

Main Menu

BPS sucks as a patcher.. beware

Started by zikey, October 16, 2019, 03:20:54 AM

Previous topic - Next topic

zikey



I thought of porting an 850 KB xdelta patch to BPS. It takes under a minute to create the patch with Xdelta -9.

BPS wants 35 minutes and 16 GB of RAM to make the same patch. And no, those aren't miscalculated values.. it almost crashed Windows. Had to terminate the process after 10 minutes. It claims to be a direct competitor to the xdelta format, even says it produces smaller files, but this is unacceptable!

mziab

I suggest using Floating IPS. It's supposed to be much faster at creating BPS patches than the reference patcher. The format itself isn't at fault here, it's the implementation. The numbers shown here are pretty crazy, though. No argument there. How big is the data exactly?

KingMike

The patcher you are using (beat?) was probably only designed/tested up to a certain filesize.

What sort of file (like the size) are you trying to create a patch for?
"My watch says 30 chickens" Google, 2018

zikey

Quote from: mziab on October 16, 2019, 11:51:14 AM
I suggest using Floating IPS. It's supposed to be much faster at creating BPS patches than the reference patcher. The format itself isn't at fault here, it's the implementation. The numbers shown here are pretty crazy, though. No argument there. How big is the data exactly?

Quote from: KingMike on October 16, 2019, 06:39:15 PM
The patcher you are using (beat?) was probably only designed/tested up to a certain filesize.

What sort of file (like the size) are you trying to create a patch for?

The screenshot is the latest version of beat.
I tried flips, it also crashes when making the patch. version v01 of beat also crashes.

The source file is a 500MB ISO image, and the patch is a translation of a PSX game, so it's full of differences:

528740286 same byte(s)
6165521 left orphan byte(s)
10349585 right orphan byte(s)
3648561 difference byte(s)


I can only assume BPS cannot scale to doing large patches of CD images.

Bonesy


filler

Byuu doesn't hang out here, but I tapped him on Twitter to see if he had any input. I quote:
"...I wholly agree with the guy. The method I used to create deltas (suffix arrays) does not scale beyond 64MB (N64/GBA) file sizes. Xdelta is much better for ISOs until someone more skilled than me can implement a rolling hash-based patch creator. It is a tool limitation and not a format limitation, but with no tools the effect is the same."

It seems clear the tool was not made for files of that size.

zikey

#6
Quote from: Isao Kronos on October 18, 2019, 01:08:49 AM
Perhaps try PPF instead of BPS?

The reason why I considered BPS in the first place is because it seemed a bit more 'popular' like IPS. Not that I really needed a replacement to xdelta, just that it might be more convenient to users with Floating IPS (which supports both IPS and BPS).

PPF would likely work as it was designed for PSX but its a bit of an old and obscure format like APS. Not really supported by popular patching programs (it's a nightmare when you encounter .aps or .ppf and have to track down the right app!)

Xdelta at least has some maintainers on GitHub, but the program has a solid pedigree and is well documented and open source.

filler

Quote from: zikey on October 19, 2019, 10:45:16 AM
PPF would likely work as it was designed for PSX but its a bit of an old and obscure format like APS. Not really supported by popular patching programs (it's a nightmare when you encounter .aps or .ppf and have to track down the right app!)

This site has all the apps. Not sure what needs to be tracked down. If it's not on this site, you can submit it. Seems pretty easy to find any patching program you need. http://www.romhacking.net/?page=utilities&category=2&platform=&game=&author=&os=&level=&perpage=20&title=&desc=&utilsearch=Go

Ansarya

@zikey I know it's been a month, but any chance I could get I copy of your source/target files? I made a .NET Core implementation of a bps patcher and I'd like to test on a larger file to see how badly it scales when creating a patch.

I'm using a brute search method at the moment instead of suffix arrays so it should be (maybe?) slower but not need nearly as much memory. With a large file test I could start looking at optimization alternatives. I'm already using Span<byte> to reduce heap allocations and speed up memory access although it reduces the maximum file size to 2GB.