News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Tater Bear

Pages: 1 2 [3] 4 5
There is no point to continue, since seems that you like only trolling people. These were my arguments, go in peace.

Sorry, if I upset you. If it helps you feel better, I plan to continue using ISP. It is a strong standard and has been around for decades and works for all files (that I would use it on) and it has many user friendly patchers ;D. When the time comes to switch patching formats, internet connections will be fast enough that I will just download pre-patched games with a torrent. In fact, I can do that right now, patches are already obsolete :o.

At any rate, I'll probably be using it for N64 hacks nowadays.  It's more suited to what I do and there isn't an issue with automation.

Congrats on having an adventurous spirit. Let us know your thoughts on the format and how it has worked out for your projects.

You really don't want to undersatand, there could be also 100% of rom hacks out there that are confortable with BPS, but they are all rom hacks that are confortable with any other patching format invented. So BPS is pointless for such hacks, got it?

I already agreed with you that BPS features are useless. There are older formats that get the job done, without annoying feature or options. Why must I keep agreeing with you, when will you ever be satisfied? I am only human, if you prick me do I not bleed?

I don't like to repeat myself, this is not true, the 90% of rom hacks out there are not for NES/SNES GBA SMD GENESIS and whatever up to 16bit console you can imagine. The whole set of rom hacks done by SadNES city is prevalently on PSX, Gemini works on PSX, every single human being on GBATemp works on NDS. Are you still sure that the 90% of rom hacks out there will find beat useful?

Hey if you feel there are more hacks available for newer systems, then be my guest. I will not try to change your mind.  :thumbsup:

If you ever get bored add up the hacks currently available for these older system (From the atari to last 16-bit systems) and don't forget the old computer systems and arcade cabinets. I am sure you are right and the entirety of several decades worth of game has less hacks than more modern system hacks that we have only just recently figured out how to hack and distribute in the past couple of years.

Not to point fingers at anyone in particular, but a lot of people do the former because of the latter....

True. (No sarcasm implied)

It seems that you can't read what I write: "BPS is a very good specification for a patching standard and I would be very happy to see new hacking projects using BPS". So, no one here is saying that byuu is an ass, don't spread something that no one has said.

Look up this word, sarcasm.

we are saying that beat is not useful at all at this state, it seems that you want to understand only what it is confortable to you.

I was agreeing with you. The fact that it works on only 90% of the existing ROM hacks, makes it completely useless.  :thumbsup:

This is not true, ROM hacking cannot stick to NES/SNES hacking forever.
Poor MD, SMS, GBA, GB. No love for them  :'(  ;)

Playstation, Playstation 2, Wii, PSP, NDS and many other gaming platforms whose games are more than 300 MB in size need a fast patching tool, regardless of the game size. As I can see, RHDN is a community devoted at very old console hacking like NES/SNES, Genesis etc. but it is slowly moving to 32 bit systems like PSX, as recently opened threads demonstrate. When BPS would become fast enough to produce patches for ISO and NDS cart images, I will definitely drop xdelta.

Even if somebody writes a faster implementation, it is pointless. If you didn't notice from several people in this thread, there is nothing worthwhile about the BPS format. There are no problems that need addressing. Clearly byuu is such an ass, that anything he writes is by extension worthless. I pray he doesn't waste his time and find some cure for cancer, then we will have to prove to everyone that it is unnecessary, chemotherapy and radiation are good enough.

Some loser in another forum is looking at making a faster implementation, but I will make sure to point him this way so he can lose interest in his project.  :thumbsup:

The only thing that a new format could bring to the table would be one that works across the board from tiny to biggest files. And beat just fails here, end of story. But it's ok, continue throwing a tantrum.

Yeah, h.264 was a waste of time when it was developed. The reference encoder was slow as hell and there was no alternatives at its finalization, but some idiots decided to do their own implementation based on the spec and created x264. Morons, the only new thing it offered was HD and a Mpeg could still be made to do that. People should always stick to the first implementation and use that to judge a format. I wish everyone was as smart as you KaioShin, but unfortunately they are not and we are stuck with stupid formats like h.264. The worse part is now we have h.265 and the reference encoder is even slower, please educate the world about how pointless it is.

A patching format is not user-friendly, it is a patching format, period. The motivation behind the existance of many frontends for xdelta is that the programming API for generating and applying xdelta patches is horribly programmed and not documented at all . Once one will embed the xdelta patching code into a GUI program, xdelta would become the de facto patching standard for the ROM hacking community. This is a problem that I was considering to resolve with Delta Patcher 2.0, that would include the xdelta3 source code inside the executable, reducing the amount of GUI widgets (like the log window).

We are talking about the application and it is great as it is, so you shouldn't waste your time writing any thing further for it.  :thumbsup:

BPS is a very good specification for a patching standard and I would be very happy to see new hacking projects using BPS but it lacks programmers at implementing a fast and optimal algorithm for generating BPS patches.

Who cares that beat functions fast enough for 90% of the ROM hacking projects out there. Nobody should use it, because xdelta is older and has less annoying features that would give us options that some of us would not use.

Yeah, xdelta UI comes bundled with a grand total of three files and one is a readme. It doesn't get more easy and simple as that. Who cares if it's a front end, it does the job very well.

I give up, you guys lack the ability to read.  Xdelta UI is always the first thing that pops up when I search "xdelta", but I don't know why people write frontends for it anyways. xdelta is possibly the easiest software to use, that is why it has such "wide spread" use among average people. ROM hackers like me are too dumb to see that and that is why we have stuck with ips all these years.

I would say that so many people writing stuff for xdelta is proof that it's actually good/useful for most people, unlike this BPS thing...

All I can say is that that makes no sense what so ever. Xdelta has been around for awhile and that is why it has more stuff written for it. I guess we should never upgrade to different operating systems, programming languages or any new technology, because the older stuff has more things written for it and therefore are better.  ::).

 :thumbsup: Don't try new medicines either, they aren't as prescribed as the older stuff.  :thumbsup:

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.

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

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

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.

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).

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?

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.

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.  ;) :D

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  :o. I simply keep the best localized version and that is it. 

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.

I don't use soft patching on my stuff as I tend to play them on the systems directly. I don't think most of the emulators I use even allow soft patching (I have never even tried). Snes9x is adding soft patching with BPS, but that only covers the SNES.  Embedding a soft-patcher is possible with this format and that would be a universal solution for any system and wouldn't require that the end user change anything (I think). I know little about the subject of soft patching, as I don't use it. I would be interested in how many regular users soft patch their ROMs in an emulator instead of hard patching them. I think of soft patching as something only "purists" would use.

To be honest, I go with the latest/greatest thing and I think most people are like that when it comes to technology. Just look at how computer software and hardware gets away with constant updates even though there was nothing technically wrong with the previous stuff. The average user, I would think, would update their IPS patcher to a BPS patcher if it was simply a slightly newer technology with only minor improvements. In this case, BPS is far more than a slight improvement. From the end user's perspective, they would see smaller patches and would quickly know if the patch was incorrectly applied. Something that no IPS patch does for the average user.

I guess, what I am trying to say is that I don't see the average user caring about whether it is an IPS/BPS patch. They just want to play the game and if they have to download a IPS/BPS patcher they will. The people that should be caring about which patching format to use is us, the creators of the patches. The average user will use what ever we use, so we might as well give them the best quality patches we can offer.

I don't really see a point to byuu's continued revisions of his patching format. They basically just suit his uses.

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 have no use for folder patching, but all the other features of BPS suit me just fine. I think most ROM hackers could make use of the other features as well (The most important one being stored checksums).

I am sure there are many people that can make use of folder patching. I can see it streamlining the mod process for old PC games. I recently updated Thief 2 and Oni for play on my windows 7 OS. The mods included modifications to the resources and executables of the games (To allow increased resolutions, new HD graphics, proper function in newer versions of windows, and other neat features), which goes without saying that multiple things needed modification/patching in the games directories. I think it is fairly narrow-minded of you to dismiss this feature just because you personally don't have a use for it. Your shortsightedness makes me seriously want to make a new installation of Thief 2 and created a BPS patch of the directory with all the mods included... Honestly, saying that it just suit his uses, comes off as if though you have some personal issues with him and I would like to keep that unnecessary drama out of a serious discussion of the merits of this patching format for this community. Discuss BPS or beat, but not byuu.

Anybody mind if I port this to Linux using nimrod? It converts code to C which it compiles. I'll probably add a quick GTK UI on top of it similar to the one in the screenshot. Been looking for something I could contribute to the community.

I never heard of nimrod before, I think that is an interesting idea. Please share the results with us, when you port it  ;D.

Check the other posts in the thread, it's horrible for CD based games currently.

It is conditional on the CD/system. If the CD contents are treated like a folder structure and it has no files that are bigger than 100mb then it could work. I imagine the biggest problem, for certain systems, would be that the end user need to know how to rebuild the disc.

It is worth noting that beat is only slow for the creation of patches for large files. It can apply those same patches quickly with no problems. So if a ROM hacker wanted to use beat with a slightly large file it would only affect him, not the people that the patch would be distributed to. The slow patch creation on large files is not an issue with BPS, but just with the implementation found in beat.

Only disc isos, but from what I've been hearing that only applies to earlier CD games.  I honestly assumed most games distroed that way in my earlier post.

Earlier CD games could/might work, if the user is expected to rebuild the game disc themselves.

That said I don't recommend this for anyone hacking disk consoles.  Stick with xdelta when doing delta patching if you want to use your computer for the next few days.

If the CD is treated as one big file (iso or bin), then that is definitely going to be a problem. But if the CD contents are treated as a directory, then it can work well for some systems/games.

Hopefully, down the road a delta knowledgeable programmer can write faster delta code that will allow beat to be feasible for large files. For most ROM hacking projects, beat's implementation is fast enough.

I liked NINJA but byuu's format looks promising.

Good news is that the format is complete, so there are no worries about BPS files made now being incompatible down the road.

I also learned that the Snes9x team is going to add soft patching with BPS files to the emulator.

Doing Delta patches for large files is slow, but byuu noted this as well and wrote "We just need someone who -really- understands delta encoding to help make a more effecient delta algorithm for files > 100MB".

Of note, there is already another separate implementation available. Screwtape has developed one in python and it can be found here. Screwtape has posted his test results as a spreadsheet here and as you can see BPS is capable of some very impressive small file sizes.

If you wish to try writing your own implementation, the spec for BPS can be found on the beat homepage.

Pages: 1 2 [3] 4 5