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

Author Topic: Creating a Patch for a Dreamcast Game (GDI format)  (Read 2678 times)

sharksnack

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Creating a Patch for a Dreamcast Game (GDI format)
« on: February 21, 2019, 01:02:26 am »
I'm currently working on an English translation for the Dreamcast version of Asuka Kenzan, but I noticed that the file size for track 3 was significantly larger after rebuilding with GDIBuilder when preparing the files for a patch using xdelta. (see: https://i.imgur.com/aGz23pI.png)

Is it normal for rebuilt games to have that large of a difference? And if not (I assume it's not), could someone point me in the right direction for preparing Dreamcast files for a patch / how that process goes?

GDIBuilder page for some additional context, if it helps: https://projects.sappharad.com/tools/gdibuilder.html

FAST6191

  • Hero Member
  • *****
  • Posts: 2648
    • View Profile
Re: Creating a Patch for a Dreamcast Game (GDI format)
« Reply #1 on: February 21, 2019, 04:25:39 am »
If the xdelta patch is that much larger it usually means you want to increase the look ahead window -- by default it will only scan ahead a certain distance to see if it finds where the data landed instead, if it is not far enough it will instead assume it is a change and make a patch accordingly, with said distance easily being achieved with the average optical media system. It will make patch making a fair bit longer (more to search after all) but should get that size down.
I don't know what the modern xdelta command line switches will be offhand but it should be there in the help/usage.

Alternatively if it is really a problem then you can bundle a tool to pull individual files/tracks, patch those by themselves and then reinsert the files/tracks or otherwise rebuild the iso.

sharksnack

  • Jr. Member
  • **
  • Posts: 15
    • View Profile
Re: Creating a Patch for a Dreamcast Game (GDI format)
« Reply #2 on: February 21, 2019, 11:29:40 am »
Thanks for the reply.

That's good to know regarding xdelta and I'll definitely keep that in mind, though right now the main concern I have is that the size of the game files grows by 722MB after rebuilding using GDIBuilder (before any patching is done). That doesn't seem normal when I've only edited text in two files, and I'd like to avoid having people download + take up that much extra space, so I was hoping to get the file size down when rebuilding prior to patching.

FAST6191

  • Hero Member
  • *****
  • Posts: 2648
    • View Profile
Re: Creating a Patch for a Dreamcast Game (GDI format)
« Reply #3 on: February 21, 2019, 12:54:58 pm »
I am less familiar with the specifics of the GDI format here. That much size increase I would expect to see only when the iso rebuilder decides to pad out a section or the iso, assuming said files are not likely to boost that much in size (no adding a 5 hour cutscene when it started out as 2 minutes sort of thing) and there are no compression or encryption worries.
If it is simple padding then I would have expected the compression xdelta does to sort that, if it is random padding then that might be a different matter.

Sappharad

  • Jr. Member
  • **
  • Posts: 16
    • View Profile
    • Sappharad.com
Re: Creating a Patch for a Dreamcast Game (GDI format)
« Reply #4 on: December 06, 2019, 10:54:33 pm »
Probably very late for this reply, but I'll provide it anyway since someone else could find it via a google search some day. Hopefully you already figured this out and never got a reply.

When you rebuilt your GDI, you forgot to select the CDDA which is track04.raw in your screenshot. Instead you generated a 3 track disc which puts all of the game data in track03.bin, but there was no game data in track03.bin previously.

In a GD-ROM all data is stored at the end of the disc because the outside is spinning faster than the middle so data reads back more quickly there. This was done on the original system to improve loading times. In the case of games with CDDA, track 3 only contains the file table that tells the system where files are stored, all of the actual files are stored in the final track after the CDDA. In your game, there was 1 CDDA Track (track 4) so all of the game data is in track 5. The original track03.bin was just a file table followed by empty padding to fill up the disc.

In other words, all of your changes were supposed to be in track05, but instead the entire disc was in track03. The patch you generated would contain all of the game data, because your patch would turn an empty track file into a file containing all data. In your screenshot, tracks 04 and 05 are completely useless because GDIbuilder did not know about the CDDA and built you a 3 track disc. (You built over an existing image so the files are still there) By re-building the disc image with the CDDA present you would have gotten three files updated (disc.gdi, track03.bin and track05.bin) and all files would then be used as they were before. This is also important to note, because your patch would need to account for all 3 of those files changing.

I hope this makes sense.