Translating Grandia

GO TO ADMIN PANEL > ADD-ONS AND INSTALL VERTIFORO SIDEBAR TO SEE FORUMS AND SIDEBAR
Joined
May 12, 2007
Messages
195
Points
43
Thanks, I've already identified, disassembled and reversed the decompression function. My function does work correctly until some position into the second tile, then it breaks and produces garbage. I've already a suspicion why this happens and I think the function will be done today. Then comes the hard part, writing the compression function.

I don't want to jump too far a head, but at some point we need the tile data from the English ps1 version. Do you already have the translated tiles?
Making the tile data isn't hard. I've done it for a few other parts already. So that shouldn't be an issue.

Sometimes, if there is free space and the amount of data is small, you can place there the already unpacked data by the game itself. Thereafter you need to prohibit access to the unpacking procedure. Unpacked data will be directly read from disk to the desired address in RAM, and then written to video memory.
In this case, you do not need to spend time analyzing the algorithm for packing data and writing a decompressor / compressor.
PS: I have used this method in many games, including Linkle Liver Story.
I'm not sure how well that would work here though. The data is in an 11MB file that has graphics for a lot of other stuff, some compressed, some uncompressed. I haven't really figured out how this file is parsed and read to know what kind of impact that kind of change would have on everything else. The uncompressed graphics I'm looking at for this part look to be about 3x as big as the compressed data.
 

nanash1

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 

Attachments

  • Like
Reactions: vbt

klarth

New Member
Joined
Aug 10, 2003
Messages
20
Points
3
Might be a variant of delta coding?

 

nanash1

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Last edited:

nanash1

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.

 
Joined
May 12, 2007
Messages
195
Points
43
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Joined
May 12, 2007
Messages
195
Points
43
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 

Attachments

nanash1

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Joined
May 12, 2007
Messages
195
Points
43
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Joined
May 12, 2007
Messages
195
Points
43
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Joined
May 12, 2007
Messages
195
Points
43
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:

Code:
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:

Code:
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

New Member
Joined
Apr 26, 2019
Messages
26
Points
3
Age
41
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.
 
Last edited:

Jackafur

New Member
Joined
Aug 29, 2019
Messages
8
Points
1
Age
33
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.
 
Joined
May 12, 2007
Messages
195
Points
43
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

New Member
Joined
Apr 6, 2019
Messages
39
Points
8
Age
38
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.
 
Top