Tool: New Patching Format (CPS)

[Giga Universe]

I just made a new patching format. Its got quite a simple format, and is very speedy. Plus its got built in compression. I'm probably leaving this as a command line application, as I'm integrating the source into something else. It currently uses the QuickLZ library for compression, but I can change that if someone has another library to suggest. The tool is programmed in C++ and I have included a win32 binary and the source in the attachment.

Run from cmd:

cpspc [m|a] baserom patchout [modifiedrom]
m: Make a patch
a: Apply a patch
baserom: the rom to use as a base
patchout: output name for the patch file
modifiedrom: the modified rom (Only use with the 'm' switch)​

I did a small speed test: I took a FireRed ROM as the base, and a Ruby ROM as the modified file, and here are graphs showing the comparison in size, and the time it took to create and apply the patch. I know, the file size sucks, but I'm still looking for a good compression algorithm thats fast and has a reasonable compression ratio. Here are the results anyway:

If anyone is curious as to how it works, read the source... There is some documentation in there.

 

[esperance]

I could really see this becoming the staple patching system. Plus, just like Team Fail, I wanna know whether it works with NDS ROMs too.

 

[Giga Universe]

No, I didn't design it to work with NDS ROMs. It should, however, as it does support really large files. Although, the bigger you go, the better a computer you need. You need enough free RAM to equal the Base Size of the Rom * 2 + The modified size. In theory, you could patch files up to 4gb. But that would need more than 4gb of free ram. I made it basically buffer both ROMs into the RAM. I didn't think I needed to make it any other way. It should be able to patch any binary file. I can rewrite the source to handle bigger files, if enough people want me to do so.

 

[Giga Universe]

I probably could edit the code so that it works in chunks to limit the RAM usage, but that would probably slow it up. I'd probably do it if more people want it to support NDS ROMS. It was more designed to work with smaller ROMS anyway.
Anyway, something I forgot to add, is that this patching system is reversible, so if you apply it to a ROM, then immediately apply the same patch to the same ROM, you'll un-apply the patch. Just make sure you don't do any changes to it first.

 

[esperance]

I probably could edit the code so that it works in chunks to limit the RAM usage, but that would probably slow it up. I'd probably do it if more people want it to support NDS ROMS. It was more designed to work with smaller ROMS anyway.
Anyway, something I forgot to add, is that this patching system is reversible, so if you apply it to a ROM, then immediately apply the same patch to the same ROM, you'll un-apply the patch. Just make sure you don't do any changes to it first.

That's pretty cool. :) A creative feature that was unfortunately never added into the other patching systems.

 

[Urhungry]

Looks quite nice. Any chance it will work on Linux?

 

[RHIOneAlbum]

Nice :D you should make a GUI program for it :p if so, could fare against ups and aps!

 

[Full Metal]

It already contends with all the other patch systems.
A very simple shell script could integrate patching into your system's context menu for whatever types. for example, right click .gba file-> make patch, file dialog appears -> bammo. patch made.
OR double click a patch -> file dialog appears -> BAMMO patch applied. IN FACT.
I think I'll make a quick little program. If you can build it, feel free.

#include <gtk/gtk.h>//GTK+ toolkit. Using the file dialog here.
#include <iostream>//system()
#include <cstdio>//fprintf
int main(int argc,char** argv){
   if(argc<=2)return fprintf(stderr,"Don't run this program on it's own!\n");
   gtk_init(&argc,&argv);
   char* target;
   char buffer[1024];
   GtkWidget* ofd= gtk_file_chooser_dialog_new("Choose your ROM file",NULL,GTK_FILE_CHOOSER_ACTION_OPEN,GTK_RESPONSE_OK,GTK_STOCK_OK,GTK_RESPONSE_CANCEL,GTK_STOCK_CANCEL,NULL);
   if(gtk_dialog_run(ofd)==GTK_RESPONSE_OK){//User chose a file
     char* f = gtk_file_chooser_dialog_get_filename(ofd);
     sprintf(buffer,"cpspc a %1 %2",argv[1],f);
     system(buffer);
   } gtk_widget_destroy(ofd);
   return 0;
}

^ Build that and set IPS, UPS, and CPS extensions to be handled by this program. I did that in....3 minutes. Check my arguments on the gtk_file_chooser_dialog_new() function, and yes I'm aware that calling system isn't safe, but oh well. I think it's okay for no more simplicity involved in this program. I guess I could always use g_threads and fork(), but eh.

 

[IIMarckus]

What advantages does this provide over other ROM patching formats (or even xdelta)?

Why compress internally over zipping it up?

That's pretty cool. :) A creative feature that was unfortunately never added into the other patching systems.

UPS does this, I think. But I wouldn't recommend UPS ever since byuu (the developer) disowned it.

Looks quite nice. Any chance it will work on Linux?

Compiles fine here:

$ cc -c -o quicklz.o quicklz.c
$ c++ -c -o main.o main.cpp
$ c++ -c -o patch.o patch.cpp
$ c++ -o cpspc *.o

But the code assumes the wrong number of arguments (in Unixen the first argument is the name of the program).

 

[Urhungry]

$ cc -c -o quicklz.o quicklz.c
$ c++ -c -o main.o main.cpp
$ c++ -c -o patch.o patch.cpp
$ c++ -o cpspc *.o

But the code assumes the wrong number of arguments (in Unixen the first argument is the name of the program).

I'll try it out too, thanks.

 

[Giga Universe]

Just so you know, this is not supported any more, as I am integrating it into SkyDock, so that will be the GUI. The reason why it's compressed beforehand is because it will be SkyDock's backup format, so you won't have a chance to compress it. Plus its faster... (You don't have to manually zip it).
It has the advantage, because its designed for high speed and low size. The ratio between the two is mainly dependent on the compression algorithm used.
Its great speed is due to the format, it has no blocks or chunks, therefore, no checks are performed, it is literally the XOR of both the base and the modified ROM. This is also why it needs to be compressed.

 

[miksy91]

Does it have some advantages compared to Lunar IPS for instance ?

E.g. Lunar IPS writes data this way:
[Address (3-byte)][Number of bytes to re-write (2-byte)][Data to write]

 

[Giga Universe]

Well, like APS and UPS, it's XOR based, so it can be reversed if you reapply the patch immediately. Also, when uncompressed, its much faster than all three, as it's chunk less. When compressed it's still faster, as the compression is built in, saving you the effort of compressing it yourself.

 

[Full Metal]

Also, you CAN use NDS roms, even if you don't have 4GB of RAM.
It will just be kind of slow, because your PageFile ( located on your HDD )
Will keep being re-accessed many many times by one program.
HDD is significantly slower than RAM memory.

 

[Giga Universe]

I will probably rewrite this so that I don't have the buffer the ENTIRE Rom, but the compression library I'm using apparently requires you to buffer the whole thing. If I do rewrite it, it will use GTK+ zlib implementation, and I will then be able to buffer in smaller chunks. This will slow it down, but you will then be able to patch massive files. If I make the buffer large, then it won't slow it down too much.

 

[Lugiaz Soul]

Make so it has an option whether you're patching a small or big rom.

 

[jvpski3]

Seemz nice, plan to put it on rom hacking dot net?