 |
|
 |
|
| Posts by byuu |
|
|
|
|
|
|
|
|
> it's still physically impossible to complete Speedy Gonzales (and I'd actually like to know how that works)
Speedy Gonzales has a programming flaw where it gets stuck in an infinite loop. It continuously reads from a non-existent register, which returns the CPU MDR (also known as open bus, basically the last value read or written that was valid.) The MDR value it reads back doesn't satisfy the bit-test to break the loop, so the game hangs.
The way bsnes and real hardware get out of the loop: the game also has HDMA running. It's unbelievably rare, but after a few million loop iterations, the cycle after the last memory fetch and before the MDR fetch will trigger an HDMA that just so happens to read in a value that is capable of satisfying the bit test to exit the loop. The HDMA read updates the MDR.
Emulating this requires a true cycle-accurate emulator. But you can also get around it by hacking the game to fix the bug. The former will never happen with Snes9X, because it'd be too slow for them. The latter is a distinct possibility, hampered by the fact that it's not a popular game for them to care about.
|
|
|
|
> It is apparently much more accurate than any other patching system
Already said but yeah, there's no benefit to accuracy over UPS. But over IPS, it's benefit is verifying you used the right source file.
> So, would we ever make a move to BPS patches?
The delta patching does produce smaller file sizes.
See the table here:
http://byuu.org/programming/bps (same format, just an older version of the program tool that didn't do folder patches yet)
On non-encrypted translations, BPS patches can end up nearly half the size of IPS and UPS.
This really doesn't matter in 2012 with 3TB hard drives.
On delta files (SNES games don't use this), it can be far better, like 90%+ better.
The main advantage in the SNES world is that it avoids the "do I apply the patch against a game with a copier header, or without one?"
A) both bsnes and Snes9X apply it after the header: you can use a headered or unheadered ROM, a BPS patch, and it will just work
B) it checksums the resulting data to make sure the patch was applied to the right game
So unless you guys here have frequent people complaining about header or no header, there's no reason to change.
> Please specifiy where that specific expansion of the string "BPS" originates.
I added a folder patcher for eg PC game translations and whatever else, these are BPM files.
So you get "beat patch - single", "beat patch - multiple"
And it's easier to say "beat patch" than "BPS patch" (which is a redundant acronym)
|
|
|
|
> And exactly how old is the last stable version of this? It appeared on RHDN just a few days ago.
HJRodrigo posted it there. It wasn't there sooner because I do not use that site at all. I don't care for the site's leadership.
Work started on the format in 2010, and was finalized in August of 2011. The most recently released version was from August 2012.
> byuu is some kind of ninja; he reads threads while logged out and doesn't log in until he wants to post.
Your board doesn't remember my login cookie for some reason. So there's no need for me to login until I want to post.
> I'll probably have a closer look at this program then see if can start making .bps the standard in SM64 hacking.
That sounds really neat, I appreciate that 
blargg had some good ideas about delta patching, so we may be able to speed up the delta mode for games >100MB as well here soon.
|
|
|
|
> Byuu does mention something about it being Endian free on his site
The patch format is endian free, not the patch input files. The latter would be quite impossible.
However, it probably will solve your V64 vs Z64 problems if you make a custom beat patch applier (let's call it beat64)
beat stores the checksum of the input file. So take an input file, and see if its checksum matches. If it does not, reverse the endian of the file and compare again. If it still doesn't match, error out. But if so, then you know the endian was swapped. You can convert the format, patch the file, and optionally convert it back when finished.
If you want my opinion, you should mandate that all BPS patches are made against Z64 ROMs. But allow beat64 to apply them to V64 ROMs as well using the above trick. You can still allow BPS patches in both formats, and use the checksum trick.
But with a new format, this is your chance to set a consistent standard.
|
|
|
|
The delta creation speed is a known problem that will be fixed eventually, but you only make a patch once so it's not the end of the world. Delta patch application is lightning fast.
As for compressibility, it depends on what the input is.
Linear will beat delta post-compression if the data is easily compressible and little to no insert/deletes have been done in the middle of the file. This is because ZIP/7z/etc are better at compressing data than BPS, which is essentially LZSS (fancier RLE.)
Mystic Ark (J) -> Mystic Ark (U)
bps: 252,938; bps.7z: 165,761
Xdelta3: 342,946; Xdelta3 -9: 219,223
bsnes v079 -> bsnes v079
bps: 234,315; bps.7z: 187,818
Xdelta3: 357,276; Xdelta3 -9: 195,844
Xdelta -9 will probably win more, especially when you put it in an archive afterward. That is essentially three layers of compression (Xdelta layer, -9 layer, ZIP layer)
bps is meant to be a simple format that can be implemented in ~10 lines of code. To me, that's more important than having the absolute smallest patch possible. Try and implement your own Xdelta patcher to see what I mean. I wanted emulators to be able to add soft-patching support, so it had to be simple.
Anyway, you're welcome to use Xdelta as your preferred patcher if you want. If it doesn't work for you guys, that's understandable and cool with me. Thanks for trying it either way.
|
| Last edited on 2012-11-04 12:37:20 AM by byuu. |
|
|
|
Here's more results on bps v Xdelta with regards to size:
https://docs.google.com/spreadsheet/pub?hl=en_US&key=0Al7sXgOl0faodHJMdGowQ2tkSHRlZkZiekpOS0tndVE&hl=en_US&gid=1
I also just tried it against essentially 16MB of line noise (MAME UPX i386 vs i686); Xdelta -9 only wins by 1% on the absolute worst-case input. Both bps and Xdelta get bigger when compressed again. I'm actually kind of surprised you saw such a huge difference with your example, but outliers do happen.
Also, as you can see, the implementation makes a big difference, moreso than the file format itself. The implementation in bps can change while maintaining the same file format, so it's possible to make smaller BPS patches than my tool makes.
Anyway, yes. Delta patch creation speed is a huge problem. It basically takes ~15-30 minutes for a 16MB file. If it's a deal-breaker for you, re-evaluate it when we find a way to do O(n log n) comparisons to find the deltas. Or don't. So far, it's eluded both myself and Screwtape. It's a *very* hard problem.
|
|
|
|
Man, for whatever it's worth ...
You all have my sincerest apologies. It seems that I keep coming up with new things, and that causes you guys a bunch of trouble each time with "stay on this tool or switch to that tool." It was never my intention to be responsible for that.
xkcd.com/927 really did nail it, eh?
Side note: have not tried FLIPS yet, but thanks for making it. Please be sure to include an option to bypass the checksum verification so that multiple patches can be applied, and forgive me if this was already done.
|
|
|
|
|
|
|
|
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 28
|
|
|
|
