Here's the problem with these new formats:
They suck at the same things IPS sucks at, for no good reason.
xdelta, UPS, BPS, and NINJA are all improvements over IPS. Only things IPS has over them is its simplicity and wide spread use.
Any proper replacement needs to:
- Support multiple ROMs without requiring multiple patches.
Part of the BPS spec, it is blind to file type. I misunderstood, the point. You can simply just not use the file verification option and your BPS patch will work fine on multiple ROMS.
Part of the BPS spec, there are no file size limits (Unlike IPS), meaning large files ARE supported
- Support a range of game sizes, from 16k NES ROMs to multi-gigabyte PS3 titles.
Simplicity is part of the BPS design goal
- Require little to no effort for end-users to use.
BPS was designed so this could be done.
- Provide for soft-patching, at least on older/smaller games.
BPS allows for extremely small sized patches (especially when compared to IPS) and has been demonstrated to be capable of beating xdelta patches
- Produce reasonable patch sizes for most cases.
Since you specifically are talking about formats, I guess you will support the BPS format, as it can do all those things in your list and it doesn't suck at all the things IPS does. Just look at the specification.
I recently discovered BPS can do patch-stacking just fine, only difference is its files are smaller than IPS files
. If you don't know how to program and want to try it for yourself, I recommend you use V03 of beat as it has a check box to ignore checksums.
People here seem to be stumbling over the difference between a format vs implementation. That is why in my previous post I brought up h.264. As a video format, its spec allowed for many things and it was featured packed with options. Its primary purpose was to allow the playback of HD content from smaller files. Its reference encoder sucked horribly and many computers could not even playback the files at full speed. Was this a problem with the spec? Not really, it was a problem of the implementations. There were people that argued that the format was unnecessary and that a ASP MPEG-4 (h.263v3) could playback HD content and at full speed just fine. In fact, some went as far to say a MPEG2 (h.262), was good enough for HD playback. Some people even said that playback and use of h.264 files would only be possible if there was hardware support, as software was not practical. The X264 team wrote their own implementation of an encoder, even though reasonable HD playback was not possible on most computers (Which is not an issue with BPS), and it has now become possibly the best video encoder on the planet. Several groups have written codecs that allowed for full speed playback of h.264 through software (Core was the first and divx and ffmpeg soon followed) on slower computers. Keep in mind that the naysayers were people against change and not technical minded, fortunately the video encoder community is not filled with narrow minded people, but people that look to the future.
Lets compare formats at launch
|Reference Encoder speed||Slow on small and large files||Fast on common file sizes, slow on large files.|
|Reference Encoder quality ||Horrible. Loses in image quality to encoders for other formats and is not user friendly.||Excellent. Beats ISP files in size and can even beat xdelta on several files. It is simple to use and has a help menu.|
|Specification||Complex.(when compared to ALL its competitors)||Simple. (When compared to xdelta)|
|licensing||Fee must be paid.||Free.|
I am amazed at the differences between communities. Is it that the video encoding community is more progressive than this one? We have a format that is light years ahead of h.264 when it was released, yet all we can do is discuss how we should stick to older formats. Thanks to the video encoding community moving ahead and using/supporting h.264, I can now download and watch HD movies in excellent quality at fraction of the size it would have taken for one of the previous formats. A format like BPS can grow with the community. It can work for the small hacks we do now and it will work for the large patches we do in the future. BPS can work with large files, beats implementation is what is slow for creating patches of large files. In fact, you can make a patch for a large file with the current version of beat if you are simply willing to wait a loooong time for it to finish (I know people that leave their video encoder encoding a file for days). That file that took awhile to make will work just fine for the end user (patch application is not slow for large files). There are at least two individuals I know of that are working on faster encoders for BPS (One of them is byuu).
Edit: Fixed my misunderstanding of Kiyoshi Aman's first list point, and corrected a few more ISP vs IPS typos.