Shiru, an IPS-to-BPS converter would be like converting a JPEG to PNG; you'd have to fill in blanks and provide a false sense of security. It'd have to be done semi-manually, with the user verifying that the IPS-patched file worked properly before making a BPS patch for it.
tepples, I took the comparison to be about the formats themselves, rather than implementations. So like you, I see Xdelta3's speed as mainly that it has a mature implementation, rather than a benefit of the format itself.
So a BPS patch has three checksums: that of input file, patched output file, and patch itself? If so, wonderful, as that gives a high degree of confidence, and if there's an error, points to the cause.
Ambiguities are a nasty problem with IPS. I remember writing an IPS decoder and having to use heuristics in decoding some. It reminds me of the issue with HTML parsing, where the maxim of being lenient on what you accept was taken the wrong way and taken to mean to not even complain if something was out of spec, leading to people never even knowing that their pages were out of spec since most things didn't make a peep.
bsnes and headers
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
qwertymodo
- Posts: 775
- Joined: Mon Jul 02, 2012 7:46 am
Re: bsnes and headers
Yes, it does. And yes, it is.blargg wrote: So a BPS patch has three checksums: that of input file, patched output file, and patch itself? If so, wonderful, as that gives a high degree of confidence, and if there's an error, points to the cause.
Re: bsnes and headers
Yes, but if they don't wish to step out of their comfort zones a bit, I would rather they not say things that would needlessly discourage any further innovation. They should just ignore the subject, and let those that are interested discuss and criticize (constructively) the subject matter. Then again I am for free speech, so I guess I am not one to talkblargg wrote:I take you as basically asking people to step out of their comfort zones a bit and give some things a try and really scrutinize them, so that the developers can fix problems and then put them out there again for further evaluation.
.I agree. I worked for a time as a researcher (In genetics and microbiology, nothing of use here) and became an idealist of sorts, when it comes to the sharing and expanding of knowledge/information. I refuse to believe that anything is an end-all solution, when it comes to technology. The moment we think like this, then progress stops. I believe that in any scientific field (including computer science) we should always attempt to test and/or build upon the work of others. I think BPS is an interesting approach because, in a sense, it builds upon the prior work of two patching formats. It is not a revolutionary idea, but it is an "evolutionary" one that can have a practical use for many.blargg wrote:...always allowing for it not being the end-all format...
Sometimes researchers do need to "pimp" their ideas/discoveries or else all the work they have done may not receive any scrutiny. Finding the balance to getting interest in ones work with out being a little bit controversial or grandiose is a tough one.
Re: bsnes and headers
> If creation of Xdelta3 patches is lightning-fast, then couldn't one create an Xdelta3 patch, parse it, and represent the same data in BPS format?
That may or may not be possible, the problem is that Xdelta3 is a monstrously Byzantine format. It would probably be harder to learn how to parse it than how to do the delta comparison >_<
> Shiru, an IPS-to-BPS converter would be like converting a JPEG to PNG; you'd have to fill in blanks and provide a false sense of security. It'd have to be done semi-manually, with the user verifying that the IPS-patched file worked properly before making a BPS patch for it.
Correct. Also on my forum, someone already converted every completed SNES translation from RHDN into a big BPS patch archive.
> So a BPS patch has three checksums: that of input file, patched output file, and patch itself?
Yes. But one choice I made was to use CRC32 instead of SHA256. The idea was that CRC32 can be implemented in a one-line function, whereas SHA256 is not so simple. But aside from malicious intent to deceive, that gives you only a one in four billion chance of a false pass in the worst case, and a 1:2^64'ish chance in the best case. I favored simplicity of the spec over cryptographic-level security. And besides, SHA256 will likely be broken eventually, anyway.
Another point to show how much thought I put into the patching format: the hashes always come after the data, that way you can calculate the hashes at the same time as you read/write the files, if you so choose. For creating patches, it means not having to seek back and rewrite data, and not having to buffer the whole patch in memory.
> It reminds me of the issue with HTML parsing, where the maxim of being lenient on what you accept was taken the wrong way and taken to mean to not even complain if something was out of spec, leading to people never even knowing that their pages were out of spec since most things didn't make a peep.
Yep. Another fun one we've found was that some patches would seek backward in the file (use a lower offset after a higher previous offset), and at least one patcher couldn't handle that when it was streaming the output.
> I refuse to believe that anything is an end-all solution, when it comes to technology.
Definitely. If a more suitable format than mine emerges, I'm all for it.
Really, the primary driving force for BPS over Xdelta was that I wanted to see soft-patching support in emulators. And we have that, Snes9X had no trouble supporting it. Whereas I know of no third-party implementation of Xdelta.
When fighting about sizes, it becomes like compression. Do you use ZIP (ubiquity and simplicity), 7zip (great compression, somewhat popular), or KGB Archiver (ten hours to make an archive, but they are certainly the smallest)? bsdiff -destroys- Xdelta (by 3:1 or better) on x86 program diffs. Google's Chrome diff destroys bsdiff even. But those are highly specialized.
So honestly, it depends on what you're doing. I think Google's Chrome diff is wonderful for how it is used and what it does. But I'd never use it for an SNES fan translation.
That may or may not be possible, the problem is that Xdelta3 is a monstrously Byzantine format. It would probably be harder to learn how to parse it than how to do the delta comparison >_<
> Shiru, an IPS-to-BPS converter would be like converting a JPEG to PNG; you'd have to fill in blanks and provide a false sense of security. It'd have to be done semi-manually, with the user verifying that the IPS-patched file worked properly before making a BPS patch for it.
Correct. Also on my forum, someone already converted every completed SNES translation from RHDN into a big BPS patch archive.
> So a BPS patch has three checksums: that of input file, patched output file, and patch itself?
Yes. But one choice I made was to use CRC32 instead of SHA256. The idea was that CRC32 can be implemented in a one-line function, whereas SHA256 is not so simple. But aside from malicious intent to deceive, that gives you only a one in four billion chance of a false pass in the worst case, and a 1:2^64'ish chance in the best case. I favored simplicity of the spec over cryptographic-level security. And besides, SHA256 will likely be broken eventually, anyway.
Another point to show how much thought I put into the patching format: the hashes always come after the data, that way you can calculate the hashes at the same time as you read/write the files, if you so choose. For creating patches, it means not having to seek back and rewrite data, and not having to buffer the whole patch in memory.
> It reminds me of the issue with HTML parsing, where the maxim of being lenient on what you accept was taken the wrong way and taken to mean to not even complain if something was out of spec, leading to people never even knowing that their pages were out of spec since most things didn't make a peep.
Yep. Another fun one we've found was that some patches would seek backward in the file (use a lower offset after a higher previous offset), and at least one patcher couldn't handle that when it was streaming the output.
> I refuse to believe that anything is an end-all solution, when it comes to technology.
Definitely. If a more suitable format than mine emerges, I'm all for it.
Really, the primary driving force for BPS over Xdelta was that I wanted to see soft-patching support in emulators. And we have that, Snes9X had no trouble supporting it. Whereas I know of no third-party implementation of Xdelta.
When fighting about sizes, it becomes like compression. Do you use ZIP (ubiquity and simplicity), 7zip (great compression, somewhat popular), or KGB Archiver (ten hours to make an archive, but they are certainly the smallest)? bsdiff -destroys- Xdelta (by 3:1 or better) on x86 program diffs. Google's Chrome diff destroys bsdiff even. But those are highly specialized.
So honestly, it depends on what you're doing. I think Google's Chrome diff is wonderful for how it is used and what it does. But I'd never use it for an SNES fan translation.
Re: bsnes and headers
I tried finding it and failedbyuu wrote:Correct. Also on my forum, someone already converted every completed SNES translation from RHDN into a big BPS patch archive
, how big is the download or do you have a link address? I would love to compare the file sizes between the IPS files and the BPS files.