Author
|
Topic: New patching format, UPS, debuts today (Read 4 times)
|
byuu
Guest
|
 |
« Reply #120 on: April 15, 2008, 09:52:44 pm » |
|
There's no technical reason NINJA couldn't hold a delta patch as well, but I think Derrick wants to keep the format simple.
That said, I don't have any objection to another format that can handle delta. I still think UPS is the best method for any ROM-based, non-filesystem console. But yes, best tool for the job.
You're right that a spec on paper with cut operations would be trivial to implement. The problem is that you're seriously underestimating the complexity of making a patcher. LCS is an extremely difficult thing to solve, and it's flat out impossible to obtain optimal results in 100% of cases. I'd be surprised if more than one patcher ever came to be. Patch application would also not be anywhere near as easy as something like UPS, but it's trivial in comparison to the patch creator.
But then, do you make it unidirectional or bidirectional? The latter requires storing data for delete operations as well. Might as well do both to please the multi-patch crowd and the sick-of-why-doesn't-this-patch-work-questions crowd. Double complexity? Why not.
And move is pretty much needed to cut down on size, as a delete+add would require storing the data for one or both otherwise.
From here you can argue for so much other crap. RLE, duplicate, clipboard-style operations, and just on and on. You can have one hell of a paper spec that nobody in the world can write an optimal patcher for.
|
|
|
|
|
Karatorian
Guest
|
|
« Reply #121 on: April 16, 2008, 07:42:31 pm » |
|
I'm not sure if that reply is actually a damning condemnation of the idea, more tounge-in-cheek, or a little of both.
Anyway, in regards to the concerns raised. Yes, there are legitimate difficulties in implimenting such a format, especially on the diff side of the equation. However, dispite the complexities, I would aim to make this hard problem as simple as is feasible.
To that end, the format would be unidirectional, not handle compression, and not have any support any operations other than delete, insert, and move. Perhaps I should write up a draft spec and see if I can get some prototype tools developed. (If I do, I'll start a new thread, this one has been derailed enough already. My appologies.)
|
|
|
|
|
Piotyr
Guest
|
|
« Reply #122 on: April 23, 2008, 07:58:51 pm » |
|
I hate to come in on this little chat late without reading the entire thread but I don't understand half of it and the other half is muddled in with the parts I don't understand.
I have a question and if the answer is no a request.
Will ups add headers to headless roms so I don't have to muck around with the other tools to apply a patch?
If not will you put that in the patcher?
|
|
|
|
|
Deathlike2
Guest
|
|
« Reply #123 on: April 23, 2008, 08:21:56 pm » |
|
Will ups add headers to headless roms so I don't have to muck around with the other tools to apply a patch?
No. If you're ultimately concerned about the header issues (and/or good dump verification), I suggest using NSRT (for the SNES only), then use UPS as appropriately. |
|
|
|
« Last Edit: April 23, 2008, 08:27:17 pm by Deathlike2 »
|
|
|
|
Piotyr
Guest
|
|
« Reply #124 on: April 23, 2008, 11:55:28 pm » |
|
Will ups add headers to headless roms so I don't have to muck around with the other tools to apply a patch?
No. If you're ultimately concerned about the header issues (and/or good dump verification), I suggest using NSRT (for the SNES only), then use UPS as appropriately. I use snes tool but it seems quite a simple task and one that would avoid ALL confusion by just adding an option in the patcher to detect and add a header if ALL ups patches require one. |
|
|
|
|
Deathlike2
Guest
|
|
« Reply #125 on: April 23, 2008, 11:59:32 pm » |
|
Will ups add headers to headless roms so I don't have to muck around with the other tools to apply a patch?
No. If you're ultimately concerned about the header issues (and/or good dump verification), I suggest using NSRT (for the SNES only), then use UPS as appropriately. I use snes tool but it seems quite a simple task and one that would avoid ALL confusion by just adding an option in the patcher to detect and add a header if ALL ups patches require one. It's not as simple as you think. Header detection is SNES ROMs is simple if you know if it is an SNES ROM to begin with. Ultimately, you could wait for it (UPS patching) to be part of NSRT if you want an all-in-one SNES solution. |
|
|
|
|
Piotyr
Guest
|
|
« Reply #126 on: April 24, 2008, 12:43:57 am » |
|
Ok thanks for mentioning. But couldn't you just have a check for if the rom is a .smc and if it is check for a header?
|
|
|
|
|
Deathlike2
Guest
|
|
« Reply #127 on: April 24, 2008, 01:02:40 am » |
|
Ok thanks for mentioning. But couldn't you just have a check for if the rom is a .smc and if it is check for a header?
That's completely useless. You want to check against data, not against the extension. |
|
|
|
|
creaothceann
Guest
|
|
« Reply #128 on: April 24, 2008, 03:14:57 am » |
|
But couldn't you just have a check for if the rom is a .smc and if it is check for a header?
NSRT is already excellent for ROM handling. Why should the work be done twice? (Besides, UPS is a format for all types of files, not just ROMs.) Maybe you'd like one program that has a button for all your romhacking needs? ... This can work only up to a certain point, as it becomes harder and harder to maintain the source. |
|
|
|
|
Piotyr
Guest
|
|
« Reply #129 on: April 24, 2008, 04:39:48 am » |
|
But couldn't you just have a check for if the rom is a .smc and if it is check for a header?
NSRT is already excellent for ROM handling. Why should the work be done twice? (Besides, UPS is a format for all types of files, not just ROMs.) Maybe you'd like one program that has a button for all your romhacking needs? ... This can work only up to a certain point, as it becomes harder and harder to maintain the source. Well asking for one feature that is required for the patch to work itself is hardly asking for a button to cook for me and serve it to me too. |
|
|
|
|
creaothceann
Guest
|
|
« Reply #130 on: April 24, 2008, 10:23:39 am » |
|
Well asking for one feature that is required for the patch to work itself is hardly asking for a button to cook for me and serve it to me too.
The problem is that there are many systems that would need their own detection and correction code. UPS is designed to be simple, because complex formats like NINJA haven't had much success so far. |
|
|
|
|
Piotyr
Guest
|
|
« Reply #131 on: April 25, 2008, 07:38:23 am » |
|
really you would be keeping the patch simple and the patcher just a little more complex in my opinion. I was just saying that because the patch needs it anyway why not ya know? I guess you are coming from the opinion that if we add that why not add this etc etc huh?
|
|
|
|
|
Aerdan
Guest
|
|
« Reply #132 on: April 25, 2008, 10:14:34 am » |
|
The patcher is still designed to not know/mind/care what the source and destination formats are.
You really aren't getting the 'patcher works for everything' concept, are you?
|
|
|
|
|
|
RHDN Forum Archive
