ROM Hack Question How do I make a Xdelta patch for the Switch?

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country
Today I found out that I need to make a Xdelta patch to release my game mod.
How do I make one and how do I get it to work on the Switch?
 

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country
This is why GUI was made.
hu8izBt.png


Is this right?
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,405
Country
United Kingdom
crc = cyclic redundancy check. It is a very old way of comparing files for changes, and people tend to use it as a shorthand here. Anybody can fake a CRC in minutes, indeed in the tail end of the GBA era we saw Scene group release an intro version of their ROM with the same CRC value (which is what most of the ROM checking/management tools used, and still use to this day though some did move to better systems -- http://www.no-intro.org/ being a good start there) as the properly dumped stock ROM, but it will tell simple corruption or be able to identify files very easily when you know you have basic conditions.


Anyway as for the question of the OP.
Patching is used a) to make smaller downloads and b) make it so the only data being shared is the data you changed (theoretically anyway) and thus you are hopefully not sharing the copyrighted material of the original devs.
The trouble comes with massive changes, compression and encryption.
Compression can make for some radical changes depending upon how it works but most are not as bothered by that.
Massive changes are typically when someone splits apart a ROM/ISO, does some fiddling and then rebuilds the whole lot. Data then gets shifted around a lot compared to where it started out and to an utterly basic patching program (the popular IPS format used for most hacks on 16 bit and older systems, also some GBA stuff, being a top example of this) this appears a change. Newer programs will scan forward and backwards to find where it might have landed but this takes time so many patcher maker programs will only do a limited search (say 50-100 megs either way). In the patch making program there will be an option to increase this search window but at the same time increase patch making time (end user application should the same, if not quicker, and the patch will be smaller).
Encryption. Encryption almost by definition makes your file appear random, or at least randomly different, to the initial file. No patch maker simply comparing files or looking for shifts will see anything other than changes here. Known for a long time on the PC but really reared its head with the Wii custom IOS modules -- they are encrypted so you can't just make a simple delta patch as encryption makes it random and thus the change is in fact the whole file and not just your mods to it. Thus we have installers for CIOS modules. The Wii, unlike older systems, also employs full disc encryption so that is why most things there will see you fish out files yourself with wii scrubber or something, or include a batch file to do it.
I don't know the state of the Switch here, however even on older systems and to dodge the massive changes thing (as well as give people some easy options* if they needed it) the solution was usually to get a tool to break apart the ROM/ISO, patch individual files (which are probably still in the 100 or so megabyte range at most, probably a lot less, and thus still amenable to more conventional patching) and inject them back in or otherwise rebuild the lot. This then needs an executable file rather than a patch which means you either need a tool to split/rebuild ROMs/ISOs and another to patch, and the patches, which only then works for an operating system, or maybe one with a given interpreted language. A pity really when patch files can have patchers made for any system that can handle it; we have seen lots of fun and games in ROM hacking sections and forums this last few years as people shift to phones and tablets as their primary computing devices, maybe not even owing a PC, but still enjoying emulators but said same systems maybe not having a decent complement of patch applying programs.

*Jump Ultimate Stars on the DS is a nice example here. They have small tiles/cards called Koma that do special moves of sorts. They had Japanese symbols on them but said symbols were fairly meaningless even in Japanese (think comic book sound effect type things). They were translated for it but the option was given for people to leave them in the original Japanese if they preferred the aesthetic. As it just involves not patching a file that is easy to do, and the DPS patching system the guy making the patch was able to handle the DS file system to do what needed doing.
 
  • Like
Reactions: ShonenJump

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country
crc = cyclic redundancy check. It is a very old way of comparing files for changes, and people tend to use it as a shorthand here. Anybody can fake a CRC in minutes, indeed in the tail end of the GBA era we saw Scene group release an intro version of their ROM with the same CRC value (which is what most of the ROM checking/management tools used, and still use to this day though some did move to better systems -- http://www.no-intro.org/ being a good start there) as the properly dumped stock ROM, but it will tell simple corruption or be able to identify files very easily when you know you have basic conditions.


Anyway as for the question of the OP.
Patching is used a) to make smaller downloads and b) make it so the only data being shared is the data you changed (theoretically anyway) and thus you are hopefully not sharing the copyrighted material of the original devs.
The trouble comes with massive changes, compression and encryption.
Compression can make for some radical changes depending upon how it works but most are not as bothered by that.
Massive changes are typically when someone splits apart a ROM/ISO, does some fiddling and then rebuilds the whole lot. Data then gets shifted around a lot compared to where it started out and to an utterly basic patching program (the popular IPS format used for most hacks on 16 bit and older systems, also some GBA stuff, being a top example of this) this appears a change. Newer programs will scan forward and backwards to find where it might have landed but this takes time so many patcher maker programs will only do a limited search (say 50-100 megs either way). In the patch making program there will be an option to increase this search window but at the same time increase patch making time (end user application should the same, if not quicker, and the patch will be smaller).
Encryption. Encryption almost by definition makes your file appear random, or at least randomly different, to the initial file. No patch maker simply comparing files or looking for shifts will see anything other than changes here. Known for a long time on the PC but really reared its head with the Wii custom IOS modules -- they are encrypted so you can't just make a simple delta patch as encryption makes it random and thus the change is in fact the whole file and not just your mods to it. Thus we have installers for CIOS modules. The Wii, unlike older systems, also employs full disc encryption so that is why most things there will see you fish out files yourself with wii scrubber or something, or include a batch file to do it.
I don't know the state of the Switch here, however even on older systems and to dodge the massive changes thing (as well as give people some easy options* if they needed it) the solution was usually to get a tool to break apart the ROM/ISO, patch individual files (which are probably still in the 100 or so megabyte range at most, probably a lot less, and thus still amenable to more conventional patching) and inject them back in or otherwise rebuild the lot. This then needs an executable file rather than a patch which means you either need a tool to split/rebuild ROMs/ISOs and another to patch, and the patches, which only then works for an operating system, or maybe one with a given interpreted language. A pity really when patch files can have patchers made for any system that can handle it; we have seen lots of fun and games in ROM hacking sections and forums this last few years as people shift to phones and tablets as their primary computing devices, maybe not even owing a PC, but still enjoying emulators but said same systems maybe not having a decent complement of patch applying programs.

*Jump Ultimate Stars on the DS is a nice example here. They have small tiles/cards called Koma that do special moves of sorts. They had Japanese symbols on them but said symbols were fairly meaningless even in Japanese (think comic book sound effect type things). They were translated for it but the option was given for people to leave them in the original Japanese if they preferred the aesthetic. As it just involves not patching a file that is easy to do, and the DPS patching system the guy making the patch was able to handle the DS file system to do what needed doing.

I'm not sure how any of this is going to help me. I just want to make a Xdelta patch for my Switch mod.
 

masagrator

The patches guy
Developer
Joined
Oct 14, 2018
Messages
6,326
Trophies
3
XP
12,164
Country
Poland
You want to know if your patch is working.
1. Check CRC of edited file.
2. Check CRC of patched file.
3. They are the same - patch is working.

Over.
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,405
Country
United Kingdom
Any number of methods to figure out the hash value of a file, CRC then being a class of older methods for such a feat (though quicker than a lot of other things by virtue of needing to do less maths).

Most compression tools will tell you the CRC32 of the file when you compress it (might have to select it from options somewhere). Fine for small files but if you are compressing multi gig ROMs it can be more tedious.
The old school SFV format is basically a text list of CRC32 values for files it is made for.
Stuff like https://www.nirsoft.net/utils/hash_my_files.html will give you the ability to generate various hashes for files on a right click or just from running it.
Hex editors commonly have such functionality built into them.
 

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country
Any number of methods to figure out the hash value of a file, CRC then being a class of older methods for such a feat (though quicker than a lot of other things by virtue of needing to do less maths).

Most compression tools will tell you the CRC32 of the file when you compress it (might have to select it from options somewhere). Fine for small files but if you are compressing multi gig ROMs it can be more tedious.
The old school SFV format is basically a text list of CRC32 values for files it is made for.
Stuff like https://www.nirsoft.net/utils/hash_my_files.html will give you the ability to generate various hashes for files on a right click or just from running it.
Hex editors commonly have such functionality built into them.
I can use HxD to check the CRC?
 

AvatarMew

Well-Known Member
OP
Member
Joined
Sep 5, 2015
Messages
391
Trophies
0
Age
31
XP
612
Country
Yes, just open the file and go to Analysis->Checksums...->(Pick whichever option you want)
Just to clarify, I need to patch the Xdelta to my rom?

--------------------- MERGED ---------------------------

--------------------- MERGED ---------------------------
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    BigOnYa @ BigOnYa: I played the intro to far cry 5, that is like some crazy Jim Jones cult shit. Still its petty...