[Lilinda]

My understanding is that BPS has only had one revision and that was the addition of folder patching. He has stated multiple times that the spec is finalized, so I don't follow why you are saying "continued revisions".

I was referring to his past efforts on this front, he's had at least two patch formats counting this one.

What I meant when I said they mainly suit his uses only is they are usually focused on unpatching and around translation patching. One of his earlier specs was nearly useless if you wanted to apply multiple minor patches to a ROM, for instance. In, say, the FF6 hacking community, that's very, very common.

It seems like this one is more generally focused, but I keep seeing a lot of the same patterns in his work on this front is all.

[Tater Bear]

That is a good point, patch stacking is useful. I suppose creators that intended to allow this need to stick to ISP, but translation patches normally serve as the bottom most stack so they could still be released as BPS patches. In fact, any ROM hacking project that significantly alters the location of things in a ROM would get the best results from BPS and should also serve as a base patch that any stacking would be based on.

Do emulators that allow soft patching also allow patch stacking? It seems to me that it would be a nuisance to have to repeatedly soft patch a game each time you want to run it (Even worse if you plan to stack it), instead of just running a hard patched copy.

[creeperton]

.

[Lilinda]

That is a good point, patch stacking is useful. I suppose creators that intended to allow this need to stick to ISP, but translation patches normally serve as the bottom most stack so they could still be released as BPS patches.

Do emulators that allow soft patching also allow patch stacking? It seems to me that it would be a nuisance to have to repeatedly soft patch a game each time you want to run it (Even worse if you plan to stack it), instead of just running a hard patched copy.

Soft patching is easy peasy, but not compatible with patch stacking as you call it. It's basically just rename a ROM and the patch to have the exact same name aside from the file extension. Boom, you're done. I'm not a fan, I prefer hard patching so everything's in one package(And if I play FF6, I tend to put a lot of little bug fix patches and stuff on it, so there's patch stacking there as well).

[Tater Bear]

Successful adoption of a new format is about making it easy for other people to use your format.  As long as every patch that is distributed in this format comes with a nice readme that has step-by-step instructions and direct links, people will use it.

That is one of the problems with hacks, some authors fail to provide good instructions or specifics as to what ROM they hacked (headered/unheadered, interleaved or not, region, version, etc..) That is a feature I like about BPS is that it stores the checksum, so a user can know if he is at least using the correct ROM or not. I also like that the format allows metadata to be embeded with the patch.

Or, even better, if you could host the patch file along with the web patcher, and just have a button to click on and navigate to your rom.

A web patcher could easily support multiple patch formats as well... Someone should write a multi format patcher. 

Soft patching is easy peasy, but not compatible with patch stacking as you call it. It's basically just rename a ROM and the patch to have the exact same name aside from the file extension. Boom, you're done. I'm not a fan, I prefer hard patching so everything's in one package(And if I play FF6, I tend to put a lot of little bug fix patches and stuff on it, so there's patch stacking there as well).

Image if I had multiple hacks or translations of the same game... Then I would have to rename the game each time I wish to use one of them. Soft patching seems unnecessary to me, unless the goal is to have every ROM released ever  . I simply keep the best localized version and that is it. 

[KingMike]

If I may ask, what kind of drama occurred when NINJA was released?

I don't think it was drama concerning NINJA itself, but something between D (author of the format) and RHDN.

[Lilinda]

That is one of the problems with hacks, some authors fail to provide good instructions or specifics as to what ROM they hacked (headered/unheadered, interleaved or not, region, version, etc..) That is a feature I like about BPS is that it stores the checksum, so a user can know if he is at least using the correct ROM or not. I also like that the format allows metadata to be embeded with the patch.

A web patcher could easily support multiple patch formats as well... Someone should write a multi format patcher. 

Image if I had multiple hacks or translations of the same game... Then I would have to rename the game each time I wish to use one of them. Soft patching seems unnecessary to me, unless the goal is to have every ROM released ever  . I simply keep the best localized version and that is it.

Well, you're assuming people would keep multiple translations of a game lying around... most soft patching folks just grab one translation or level hack patch and then rename it to match the rom. That's all they ever do.

[Tater Bear]

Well, you're assuming people would keep multiple translations of a game lying around... most soft patching folks just grab one translation or level hack patch and then rename it to match the rom. That's all they ever do.

That is true, even I only keep one translation version, but I will screen multiple translations before I pick the one I will keep (I am pretty sure I am not unique in that regard) and it would be a pain to do multiple renames when I am switching between them as I compare them.

It would be more accurate for me to have said hacks. There are many games that have complete hacks that completely transformed the game into a new experience. Sonic 1 with Amy, Knuckles or Sally are good examples, each one is quite unique (warning there is more than one Amy hack, but only one is good). An even better example are the Super Mario Bros. hacks, there are about 20 good complete unique hacks. There are also a ton of SMW hacks that have certain unique elements to them... Some hacks flat out change the game to a completely different one, that doesn't resemble the original at all.

[KaioShin]

It's curious that you say soft patching isn't a big feature for BPS, it was my understanding that the only reason byuu wasn't happy with xdelta and had to develop the wheel anew again was because xdelta was too convoluted for him to implement soft patching into bsnes...

If you are refering to the small size improvements of BPS over xdelta when you said it was the optimal format to use, well xdetla conciously gives up compression perfection to achieve patch creation in linear time. And if you are dealing with input files that can be 10 billion bytes long (DVD9 image) that's a requirement, not something nice to have. That you have to patch discs as directories and rebuild them is a pretty hefty burden. especially on average newbie end-users. You say that's a limitation of the current implementation and not the format, well I'm betting that the size benefits are also from that current implementation and not the format, and if you'd use something faster you'd lose the size advantage instead. "Perfect" delta comparison shouldn't be possible without outrageously expensive brute forcing.

Edit: Wording and typo.

[Dwedit]

Will BPS support creating and applying patches on multiple source or destination files, or is it strictly for single files only?

Example: A FDS to NES conversion that wants both DISKSYS.ROM and a .FDS file, and generates one output file.

[Tater Bear]

It's curious that you say soft patching isn't a big feature for BPS, it was my understanding that the only reason byuu wasn't happy with xdelta and had to develop the wheel anew again was because xdelta was too convoluted for him to implement soft patching into bsnes...

I am saying, I don't think soft patching is an important factor in getting a patching format adopted by the general public. It might be important to emulator authors, but I don't think ROM hackers need to worry about whether their stuff can be soft patched by the public. In fact, when I first got into ROM hacking there was no such thing as soft patching in any emulator and that didn't stop us or even concern us.

The fact that there will be emulators that support soft patching with BPS is just a nice bonus, but it is not a deciding factor as to whether the format has any merit.

If you are referring to the small size improvements of BPS over xdelta when you said it was the optimal format to use, well xdetla consciously gives up compression perfection to achieve patch creation in linear time. And if you are dealing with input files that can be 10 billion bytes long (DVD9 image) that's a requirement, not something nice to have. That you have to patch discs as directories and rebuild them is a pretty hefty burden. especially on average newbie end-users. You say that's a limitation of the current implementation and not the format, well I'm betting that the size benefits are also from that current implementation and not the format, and if you'd use something faster you'd lose the size advantage instead. "Perfect" delta comparison shouldn't be possible without outrageously expensive brute forcing.

BPS has smaller sizes than xdelta? I noticed that a compressed BPS created by screwtape's implementation beats xdelta's according to the spreadsheet, but I kind of assumed xdelta files might still be able to be compress down a little bit more. Although, I did read somewhere that xdelta files compress poorly, because they are already compressed (It is part of the spec?). Either way, I don't know much about xdelta, so I can't really comment on it other than to say I thought the negative with xdelta was its complexity to implement and use. I was pretty sure that xdelta could win in file sizes and was the most "optimal" in terms of small patch sizes, but I may have to look into that. I do feel BPS can provided better quality patches thanks to its many features.

Will BPS support creating and applying patches on multiple source or destination files, or is it strictly for single files only?

Example: A FDS to NES conversion that wants both DISKSYS.ROM and a .FDS file, and generates one output file.

He said the spec is done, so I think it is safe to say that he will not do anything that will change it. Are you against distributing a patch that contains the DISKSYS.ROM data inside it?

[Kiyoshi Aman]

Actually, ROM hackers should be concerned about soft-patching, for several reasons:

• It allows them to test interactions between multiple patches without having to apply them individually.
• It makes it easy for end users to use patches because they just have to put the patch and the ROM in the same directory.
• Soft-patching makes prepatched ROM distribution that much sillier. (Not, y'know, that this actually stops anyone...)

[KaioShin]

I thought the negative with xdelta was its complexity to implement and use.

But there is no reason to implement it again except for soft-patching. The reference implementation works on practically any platform and has been developed and tested for 15 years. And with a frontend it's as easy to use as picking a patch and a rom file, how much easier to use can it get?

[Tater Bear]

Actually, ROM hackers should be concerned about soft-patching, for several reasons:

• It allows them to test interactions between multiple patches without having to apply them individually.
• It makes it easy for end users to use patches because they just have to put the patch and the ROM in the same directory.
• Soft-patching makes prepatched ROM distribution that much sillier. (Not, y'know, that this actually stops anyone...)

We will have to agree to disagree on soft patching's importance (except for your last point on the list, that is a good one). It is a moot point anyways, because there are already forces out there implementing soft patching with BPS and it is technically easy to add to any open source emulator by most programmers.

Edit: Maybe the first one too, but that means I would have to have faith that it is not a bug in the soft patching implementation or emulator. I would still end up hard patching and testing on the emulator and/or hardware, so that is why I don't consider it a 100% valid reason.

But there is no reason to implement it again except for soft-patching.

Xdelta does not offer all that BPS does, so I fail to see why it is wrong to make a delta patcher that has more/different features than xdelta (regardless of whether soft patching is one of them or not)

The reference implementation works on practically any platform and has been developed and tested for 15 years. And with a frontend it's as easy to use as picking a patch and a rom file, how much easier to use can it get?

By implement, I mean writing your own code from scratch based on the spec. To many emulator authors that is important and it frees them from having to use someone else's licence. Having to download two separate programs to do a simple patch is not what I call convenient. For example, with IPS you can download just lunar ips and be done with it no real explanation required. With xdelta you would have to explain to the user that they need to download and use a frontend. But I feel this is a moot point, as I feel users are more than willing to do anything we ask in order to play a game (including downloading and running 10 programs if necessary to patch one game). This discussion is about in comparison to BPS. BPS is less complex to implement (So programmers are happy) and simpler to use (Less applications for the end user to get).

[KaioShin]

Xdelta does not offer all that BPS does

Mostly the stuff UPS already had (handling of SNES headers, embedded readme) and no one cared about back then.

To many emulator authors that is important

Only to byuu and his OCD.

For example, with IPS you can download just lunar ips and be done with it no real explanation required.

And the frontends come bundled with xdelta, so they only just download one file and are done with it too. They start the frontend and never even notice there is a command-line application running in the background.

[Tater Bear]

Mostly the stuff UPS already had (handling of SNES headers, embedded readme) and no one cared about back then.

That is the point of BPS, it offers the best that Xdelta and UPS had to offer in one format. 

You also appear to have not done your research and have issues with byuu. To my knowledge BPS is blind to file type (meaning there is nothing done special to handle headers), it works with any file type. The only reason it helps with the issue of headered/unheadered ROMs is due to the fact that the format stores checksums. BPS/beat does not handle SNES headers, unlike UPS.

Only to byuu and his OCD.

Why the hell does the world revolve around byuu for everyone? That statement is wrong on so many levels, that I don't even know how to respond to this.  I have never met a programmer that prefers to implement complex crap when there is a simpler alternative. What drugs are you on, if you think licencing is not an important issue for programmers? I guess the hundreds of different licences out there, were all developed by byuu since he is the only one that cares. Many, if not most, programmers like retaining some level of control over their work. You need to have a discussion with SteveSnake and tell him he should use other peoples code and use their licence in his work and see how quickly he will rip you a new one. This is coming from someone that recommended he use a library coded by someone else for a feature he did not have in his emulator, but I guess SteveSnake is also byuu. Please people, discuss the merits of BPS or beat, but not byuu.

And the frontends come bundled with xdelta, so they only just download one file and are done with it too. They start the frontend and never even notice there is a command-line application running in the background.

Notice I said download two separate applications. You are just repeating what I said.  Unless you actually think my issue was whether they are package together or not. If you got a temp job doing technical assistance, you would probably last only a day. A lot of people would see two applications and start freaking out, some will even click on the command line application see it pop up and think it was a virus and that now their computer is infected. The reason desktop shortcuts are necessary for the average consumer, is due to their inability to recognize main applications in folders. You presume that because you are intelligent enough to have no issue with using a frontend, that no one else will. Sorry to burst your bubble, but that is not the case for millions of people. Some people need to be taught how to properly use a program and xdelta is not the shining example of a user friendly program that you seem to think it is. (Neither is beat, but it is a hell of a lot better than xdelta).

Lets run the scenario of an average windows user. They download a Xdelta patch that is for some game and like most people they will ignore the supplied readme. They type xdelta into Google and immediately the xdelta homepage pops up as number one. By luck they actually download the correct version for their system from the looooong list of downloads on that pages download link. They pick the installer as that is what they normally do when they want a program. After it is installed they are shocked to see the program folder lacks a shortcut, so using their smarts they figure to look for it with a system search. Once the do this, they click on the icon and nothing happens (The screen flashes breifly). They then go online and learn that they need to use a frontend. So they type in xdelta frontend in and google and get a list of frontends, just as with the first search they pick the top one, which takes them to ROMhacking's page for this front end.


I will stop here as it is obvious where I am going, but I will note that frontend image looks far scarier than something like this
or

All of that is still a moot point, because I feel a user will do or learn anything necessary in order to play a game. But I find it ridiculous that someone would claim xdelta is just as simple to use as lunar ips or beat. Hell, beat even has a help button that neither of the two examples I posted have. The mere fact that there are so many frontends written for xdelta is proof that it is not user friendly.

[kode54]

Sure looks convoluted to me...

[Tater Bear]

  Did you even read what I wrote. That is not the first frontend that is seen.

[Pennywise]

You're argument on the bottom has been rendered pointless by xdelta UI, which is just as simple and easy to use like Lunar IPS.

[Tater Bear]

You're argument on the bottom has been rendered pointless by xdelta UI, which is just as simple and easy to use like Lunar IPS.

Wrong. My argument is that a simple frontend is not the first to be seen. Actually that isn't my argument, but it was a minor point to my augment. My argument is that xdelta is not user friendly. It needs a frontend in order to be close to being user friendly.

I find it odd that so many people are trying to argue, whether xdelta is user friendly, when it is almost common knowledge that it is not. You would have an easier time arguing whether a frontend for xdelta is user friendly or not, but that is not my point. My point is that xdelta needs one because it is not user friendly.