Grandia English Patch

Translating Grandia 1.1.1

I think this is the final version of my compression tool. At this point I just wanted to wrap this up and fix some bugs and problems I found while messing with character sprites. This new version doesn't really add anything new as far as the translation is concerned, unless you want to try different compression modes and tables. This release also includes the source code. If there's anything else I can help with just say it and I'll give it a try.

So I've found more compressed graphics data. The graphics for things like the Characters Names at the top of the Screen, the yellow text for the tactics you choose, and things like the pop ups for words like "Counter", "Miss", as well as weapon and skill level ups appear to be compressed and stored in every BBG file.

At a quick glance it looks like it might be going into a similar kind of compression as the other data, but when I try the decompression tool it gives me an error saying "Compression Table Invalid". So I'm guessing there's another compression table somewhere that it's using.

The data can be found in either B001.BBG at offset 0x10D96 or in the full data track iso at offset 0x26596. The decompressed data get's written to 0x4000 in VDP1's VRAM.
 
Last edited:
I used a variety of things. One of them was a plugin for 7-zip that treats image files like archives - I was actually surprised, but it showed the CRC sum as one of the file attributes. Another was the Windows checksumming tool (I forget what it's called). I can get you the actual names of all of those and the checksums produced by my own rips later when I'm not sneaking posts in during work :)
Just to close the loop on this, I went back to re-verify my results. TLDR; I can get matching checksums from my original rips now.

I made the faulty assumption that the data would be equivalent when extracted by different tools, and therefore the erroneous statement that I followed the process in your README exactly. I stopped using ISOBuster years ago because I had other tools that did ostensibly the same thing but didn't limit functionality or constantly nag me to pay for a license. I was getting different file sizes and checksums because I originally used the 7zISO plugin to checksum and extract the data track. When I re-ripped everything I decided to dig up an old copy of ISOBuster I had lying around and compare what it was producing vs 7zISO. When I extracted the data with ISOBuster suddenly I got the checksums in your readme, but I knew 7zISO worked because I've successfully used it to extract and write back tracks with other projects. HxD gave me this when I compared the ISOs:
4896



FWIW, these are the sums I got with 7zISO for Disc 1 Track 1:
CRC32: F84B3738
MD5: 062b7ef1dbe261002c5f87e76cdd0345
SHA-1: 38da4c1a55aba4ce5418d4fc35d83e7c04855c80
Size: 540,094,464 bytes

If 7zISO was doing something silly like extracting the ISO in 2352 instead of 2048, I would expect to see extra data (and for the size difference to be closer to 76MB rather than 1.5MB), likewise if it was zero-padded. Both are valid files, and based on this, I *think* the patch would work just fine even though the sums don't match because the offsets would all presumably be the same. Anyway, PEBKAC error sorted!
 
So I've found more compressed graphics data. The graphics for things like the Characters Names at the top of the Screen, the yellow text for the tactics you choose, and things like the pop ups for words like "Counter", "Miss", as well as weapon and skill level ups appear to be compressed and stored in every BBG file.

At a quick glance it looks like it might be going into a similar kind of compression as the other data, but when I try the decompression tool it gives me an error saying "Compression Table Invalid". So I'm guessing there's another compression table somewhere that it's using.

The data can be found in either B001.BBG at offset 0x10D96 or in the full data track iso at offset 0x26596. The decompressed data get's written to 0x4000 in VDP1's VRAM.
Ok. I will look into it when I'm back home from the weekend.
 
Thanks. In the mean time I've put up a video showing the progress made on the battle menus and the result screen. I think I have everything except the compressed bit I mentioned earlier:


Nice work!

I fixed the bug in the compression tool. The first problem was that the offset wasn't correct. The correct offset for disc 1 is 0x25ebc. The second problem was that this image file starts on table compressed data. This case wasn't handled in my tool until now.
 

Attachments

  • ss_grandia_comp_tool_v095.zip
    26.1 KB · Views: 311
Nice work!

I fixed the bug in the compression tool. The first problem was that the offset wasn't correct. The correct offset for disc 1 is 0x25ebc. The second problem was that this image file starts on table compressed data. This case wasn't handled in my tool until now.

Thanks! I'll give this a try and see what I can do.
 
Not sure if this is a bug/known etc. In the first Alent boss Hydra, the enemy Hot Head is instead called SUDNDEATH (one of the moves another enemy in the same boss performs). I don't think there's anything else up with this boss.

4902

I wasn't scared when I kept seeing sudndeath appearing honest
 
Last edited:
Not sure if this is a bug/known etc. In the first Alent boss Hydra, the enemy Hot Head is instead called SUDNDEATH (one of the moves another enemy in the same boss performs). I don't think there's anything else up with this boss.

View attachment 4902
I wasn't scared when I kept seeing sudndeath appearing honest

Was probably a copy paste mistake. I have it fixed and it will be in the next patch release.
 
@nanash1 Just thought I'd mention that compiling your compression tool on Linux (glibc) fails with this error:
Code:
/usr/include/bits/byteswap.h:20:3: error: "Never use <bits/byteswap.h> directly; include <byteswap.h> instead."
# error "Never use <bits/byteswap.h> directly; include <byteswap.h> instead."

Doing as it says and using <byteswap.h> allows it to compile successfully.

To check for any other portability issues, I ran scan-build and cppcheck static analyzers. While there didn't appear to be any, they did pick up a few possible issues. I've included their reports and warning output from clang in the attachment if you're interested in them; all you should need to do to view them is open the index.html files inside the cppcheck and scan-build report directories and the clang_warnings.txt file.

I also included the generic Makefile I modified for this tool which produces a debug-friendly binary.

For what it's worth, this used v090 since v095 source isn't available.
 

Attachments

  • ssgctv09.zip
    88.5 KB · Views: 305
Well, to do a proper Linux version you'd have to check the systems endianess and determine if the use of byteswap is necessary in the first place since afaik Linux isn't always little endian.
 
Well, to do a proper Linux version you'd have to check the systems endianess and determine if the use of byteswap is necessary in the first place since afaik Linux isn't always little endian.

So if it's not too much trouble, if you comment your code really well so I can easily follow what's going on (mainly because my C/C++ is very rusty/poor), I can see if I can convert it over to Java and then in theory it would be platform independent.
 
If everything is working with the last update I could refactor a few things, improve the comments and push the version to 1.0. I didn't included the source in the latest version, because my quick bug fix used the evil goto statement.
 
Would you be open to make it a GitHub repository? People could fork it from there to whatever platform/language they liked. It seems to me that it's an interesting enough tool, even outside of the Grandia translation project.
 
Would you be open to make it a GitHub repository? People could fork it from there to whatever platform/language they liked. It seems to me that it's an interesting enough tool, even outside of the Grandia translation project.
I've never used github before, but I can look into it. However, it'll be a while since I'm currently away on vacation.
 
Reading the thread about the proccess on dumping the english traduction directly on the ROM, would it be possible to do the same on Grandia Ditigal Museum? Just only talking about the texts on the menu and combats, believing that it will use the same code or a similar one.
 
I've registered just to say thank you for working on this patch. I own the game for my Playstation but it is going to be nice having it in English for my Saturn as well.
 
Looking forward to the next patch release :)
Any news from behind the scenes?

I'm still working on it. I've just been busy helping out with some of the issues the Sakura Wars team has been having lately.

For Grandia though I do have the compressed battle graphics ready to go, the problem is they need to go into every BBG file in the game. So I need to write a tool to break those files down and rebuild them so I can insert the new data more easily and with less chances to screw something up.

Also digging more into the FMVs, it's looking like they may actually be a very early variant of CRI's MPEG Sofdec codec. So if we can figure out how to get the Quick Time containers off of them, it shouldn't be to hard to use existing tools to decode and re-encode them I'd imagine. However this is still a lot of speculation.
 
I'm liking the patch delay because real life hit me hard and I don't have time to resume my playthrough.
@TrekkiesUnite118 when you figure out the fmv compression/decompression, I can provide you with the much superior fmvs from the HD remaster if you want/can use them to compress back into the game since I've bought it on steam.
 
Back
Top