Translating Grandia 1.1.1

[nanash1]

My decompression program is working. I converted the output binary data to a grayscale image to verify. The bottom part looks messed up because those image are the names and they have a different width than the other tiles. The binary data however is correct. I think I already have a basic understanding of the compression. There are however some curious parts. For example at the beginning of the function an instruction is fetched from RAM depending on an offset that is contained in the first byte of compression data. This instruction then overwrites another instruction in the function, so that a XOR instruction becomes a SUB instruction. Maybe this will make sense when I'm done with the re-compression.

 

[Mr Conan]

Might be a variant of delta coding?

Effective compression using frame-of-reference and delta coding

Most generic compression techniques are based on variations on run-length encoding (RLE) and Lempel-Ziv compression. Compared to these techniques and on the right data set, frame-of-reference and delta coding can be faster for a comparable compression rate. Mathematically, frame-of-reference and...

www.google.com

 

[nanash1]

Thanks for the link. I'm sure now it's a delta encoding combined with special handling of zero blocks. With this information it shouldn't be too hard to write the compression program.

Edit: So it turns out what I thought would be the hard part is actually the easy one. I've figured out all the different elements of the compression and even wrote a working sub function for the delta encoding. Now all that's left is bringing it all together and making a workable command line tool out of it. I don't think this should take too long.

 

[nanash1]

My compression is working. To demonstrate I made a video to show my friend. Now all I need to do is make the command line interface and documentation. Then I'll publish it here.

 

[TrekkiesUnite118]

Nice. I've been working on making new tiles based on the decompressed data I pulled from VDP1 VRAM. There's only one or two spots I've found so far where some more work might be needed as the English wont fit into the space for the Japanese tiles.

 

[nanash1]

It might be possible to expand the tile sizes. While working on the decompression, I think I may have found where all the tile properties for the battle screen are stored. If there's enough free space in the VDP1 VRAM and on the CD maybe some tiles could be expanded.

 

[TrekkiesUnite118]

It might be possible to expand the tile sizes. While working on the decompression, I think I may have found where all the tile properties for the battle screen are stored. If there's enough free space in the VDP1 VRAM and on the CD maybe some tiles could be expanded.

Yeah, that's what I'm thinking. There's also some spots where the Japanese has more tiles than are needed in English, it could be possible to use those as well.

 

[nanash1]

Here is the initial version of my graphics compression tool. It's currently only tested for the battle screen graphics and nothing else. Known issues are that XOR compression mode is not supported and that the look up table for the compression function is currently hard coded. That might be a problem when trying to re-compress other graphics. Please report all problems that you find. I'll probably release the source some time later, after cleaning it up a bit.

Edit: I forgot to mention in the readme that the offsets were tested on the Digital Museum disc. The offsets may be different for the other discs.

 

[nanash1]

The offsets for disk 1 are: 0x1003218 for the compressed data, 0x7a0108e for the table in case anyone is wondering. I'll add these to the readme for the next version.

 

[TrekkiesUnite118]

Did a quick test and it seems to be working so far:

The offsets for disk 1 are: 0x1003218 for the compressed data, 0x7a0108e for the table in case anyone is wondering. I'll add these to the readme for the next version.

Actually I think the table is in a different spot. I found it offset 0x19660474, which corresponds to being in the GMOVE.BIN file, which is where the decompression code lives. So that makes more sense I think.

 

[nanash1]

Actually I think the table is in a different spot. I found it offset 0x19660474, which corresponds to being in the GMOVE.BIN file, which is where the decompression code lives. So that makes more sense I think.

I tested these offsets and they worked. I guess there are multiple files using the same table, that's why the same table is found multiple times on the CD.

 

[TrekkiesUnite118]

So where did you find the tile properties? I'd like to take a look at that and see what I can do to expand it for the few areas that will be necessary.

 

[nanash1]

Here is the relevant excerpt from my investigation. All offsets are for the Digital Museum Disc iso.

LOOK-Tooltips
CC6020:
+1 No effect
+2 No effect
+10 Overlayed by different sprite
'ff' No effect
CC6023:
'ff' No effect
CC6024: Offset ?
CC6025: Offset ?
CC6026: Size ?
CC6027: Size ?
+1 Lines on the lower edge
+2 More lines
+3 Lines become recognizeable as neighboring sprite
CC6028: Transperancy
+1 Becomes transperant
CC6029: Type
+1 Sprite becomes distorted (Sprite type changes to distored sprite)
CC602A: ?
+1 Becomes gray
CC602B: ?
+1 Changes hue
CC602C: ?
+1 Becomes distored
CC602D: ?
+1 No effect
'ff' Becomes distored
CC602E: ?
+1 Sprite gets messed up
CC602F: ?
+1 Sprite gets messed up
CC6030: ?
+1 Becomes distored
CC6031: ?
+1 No effect
'ff' Becomes distored
CC6032: ?
+1 No effect
'ff' Becomes distored in y axis
CC6033: ?
+1 No effect
'ff' Becomes distored in y axis

CC5FE4: Combo-Tooltip
CC5FF8: Critical-Tooltip
CC600C: Defend-Tooltip
CC6020: Look-Tooltip
CC6034: Flee-Tooltip
CC6048: Map-Tooltip
CC605C: Item-Tooltip
CC6070: Magic-Tooltip
CC6084: Justin Name Background
CC6098: Justin Name
CC60AC: Feena Name Background
CC60C0: Feena Name
CC60D4: Sue Name Background
CC60E8: Sue Name

 

[nanash1]

I took a look at the tiles of the battle results screen. They're compressed by the same function but with a different compression mode. This mode isn't differential and just reads the values directly from the look up table. Adjusting the decompression function was easy, but now I'll need change the compression function to use this mode and to support different tables.

 

[TrekkiesUnite118]

So I think I have this kind of figured out for some of the tiles. It seems we can have either 0x14 bytes or 0x12 bytes of data for this data, but overall the format seems to follow this general format:

0CE8 0674 0210 2081 0000 0058 0008 0068 0018

These 0x12 bytes represent the properties for the texture that displays the word "Moves" in the "Moves and Magic" menu. The bytes break down as follows:

0x00-0x01 - Not sure but my best guess would be an ID.
0x02-0x03 - These two bytes represent the position in the texture table for the texture. 0x02 is the Row, 0x03 is the position in the row.
0x03-0x04 - These two bytes represent the size of the texture. 0x03 is the horizontal size in tiles (8 pixel increments), 
                     0x04 is the vertical size in pixels. So for this example we have 16x16 for the size.
0x05-0x06 - I'm not sure what this is but it's most likely a set of flags for certain effects.
0x07-0x08 - Not sure.
0x09-0x0A - This is the horizontal screen position of the Left side of the sprite
0x0B-0x0C - This is the vertical screen position of the top of the sprite.
0x0D-0x0E - This is the horizontal screen position of the right side of the sprite.
0x10-0x11 - This is the vertical screen position of the bottom of the sprite. (If you do the math you'll see this coordinates work out to 
                    16x16 for the size).
0x12-0x13 - Not always there but I'm not sure what it refers to yet.

So with this information I should be able to rework some of the more troublesome text icons to get more space to fit the English words.

 

[nanash1]

Maybe the size of a properties block has something to do with the type of sprite it represents. I know that some are scaled sprites and some are distorted sprites on the battle screen.

 

[Jackafur]

So I mod chipped my saturn and patched my own copy of the game and i still have no battle sprites. so as far as i can tell pseudo saturn kai wasnt at fault and my model 1 is just having issues. guess im replacing my saturn. i made a slight adjustment on the laser pot to which didnt do anything.

 

[TrekkiesUnite118]

So I mod chipped my saturn and patched my own copy of the game and i still have no battle sprites. so as far as i can tell pseudo saturn kai wasnt at fault and my model 1 is just having issues. guess im replacing my saturn. i made a slight adjustment on the laser pot to which didnt do anything.

For sanity, how does the original Japanese disc behave?

 

[Ardiloso]

So I mod chipped my saturn and patched my own copy of the game and i still have no battle sprites. so as far as i can tell pseudo saturn kai wasnt at fault and my model 1 is just having issues. guess im replacing my saturn. i made a slight adjustment on the laser pot to which didnt do anything.

Do another clean rip of your original disc at the lowest speed possible. Maybe the problem is with your iso. Also, try another CDR.

 

[Jackafur]

For sanity, how does the original Japanese disc behave?

yea the retail copy of the game does the same thing unfortunately. If I get another saturn i'll report back but for now it just seems its just my old model 1 saturn acting up. i hooked up a multimeter to the rf and ground on the optical drive and the voltages seemed pretty reasonable. 3.18 with the game running.

Do another clean rip of your original disc at the lowest speed possible. Maybe the problem is with your iso. Also, try another CDR.

thanks for the suggestion but ive tried 2 different drives at their slowest speeds on 2 different kinds of media including jvc silvers. also like i mentioned it looks like a retail version of the game acts the same on my saturn.