+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  New Community Patch Format?
Pages: 1 [2]
Author Topic: New Community Patch Format?  (Read 1140 times)
creaothceann
Guest
« Reply #15 on: December 13, 2006, 05:50:42 pm »
It's a word play on the uncertain legal status of ROM hacking, and D's choice of the word NINJA. Roll Eyes Nothing more.
Spikeman
Guest
« Reply #16 on: December 13, 2006, 08:54:00 pm »
I would try and make a patcher or a format if I had the technical know-how. I can program but I have a hard time making script inserters, so making a patcher would definitely be beyond me.
byuu
Guest
« Reply #17 on: December 13, 2006, 10:10:03 pm »
For the record, the UPS patching library has been written and a cross-platform tool is only pending my cross-platform UI API to be completed. The spec is also open to everyone. If someone has a radical improvement that won't make implementing a new patcher seriously difficult, I'm all ears.

The *major* hurdle right now is the XML patch info format that we intend to declare as a spec. These need to be fleshed out for every target, and neither myself nor Nach have the expertise to make these for every format out there (especially the NES). Ideally, with the right XML data, patching between iNES<>UNIF<>whatever format comes out in the future, would be trivial.

I'm also possibly going to be writing a C++ version of NINJA, if I ever get around to it. Or you guys can just make your own if you don't want to wait, I don't really care. I'm not rushing this out, lest we have a new format with holes in it for the next ten years.

And for the record, detecting shifted blocks of data inside a file is a very CPU intensive and complex task. It's easy to create a format that accepts commands to cut/insert data in files, but very difficult to detect said changes in a way that anyone besides the patch format creator would be able to implement in their own patch creators. I don't have any easy solutions to this problem.
Nightcrawler
Guest
« Reply #18 on: December 14, 2006, 11:44:14 am »
Dumb question, but where are the UPS specs? You might want to provide a link. Either I'm too blind to see it, or it's not easily accessible form your or Nach's page.
Gideon Zhi
Guest
« Reply #19 on: December 14, 2006, 12:34:14 pm »
One thing I feel I should mention here is that a traditional binary patch format isn't really ideal for CD games, where you may be patching multiple files, of which there may be multiple versions, or of which scratches may create different eventual "rips." Just a thought.
Spikeman
Guest
« Reply #20 on: December 14, 2006, 05:49:16 pm »
Last night when my internet was being crappy I wrote out my ideas for a custom patcher in a text file, so I'm using the code tag to display it:

Code:
Patcher Idea
============

Creating a patch
----------------

There are several types of changes:

- Overwrites
- Relocations/copies
- ?

The patcher will scan through and find the differences between the files. This
will be stored in an array of "changes". Each "change" will store the starting
location and length of the change, then the data. For each change of a certain
size, the patcher will scan the file for it to check if it's a relocation. When
that is done, the patch will be saved in the following format:

Format
------

- Header
  - Patch Author
  - Author Comments
  - Oringal Hash
  - Modified Hash
- Data
  - Number of Overwrites
  - Overwrites
  - Number of Relocations
  - Relocations

Patching
--------

First the patcher checks if it's the right file by checking the hash. Then it
gets the number of overwrites, and changes each one. Same with relocations.
When this is finished, it checks the modified hash. If it's the same then it
saves the modified file. If it's not there was an error.

Unpatching
----------

Not possible unless when patching it makes a record of what's changed. Could
be cool to have it create an "unpatch" upon patching, instead of a backup.
Better to have option to choose between unpatch and backup.

XOR Patches. For changed data store the value that when XORed with the orginal
would result in the changed data. This way patches can be reversed. Not sure how
this would work with relocated data.
Pages: 1 [2]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC