FF8 Save File Format

[blipadeebling]

Hmm..i can see the last 3 posts are from me..i dunno maybe that pisses people off in this forum..but im not really triple posting or anything cuz they're totally unrelated topics.. never-the-less..

Im working now on the save file format for FF8, but to me it seems like there is random single byte data popping up at places where it shouldn't. For example in the naming of say Squall, certain saves may display it as "Squall" and others "Sq.uall" (where the . refer so some character/hex value) - this does not show up in the game however, just the HEX editor. Also each save file is of varying sizes, kinda strange as i didnt think stuff would be screwy like this. Is there any characters that are added to the save, that serve no purpose? Because i opened up all of the saves with Qhimm's Griever and they load fine, so something strange is happening in the save file format, that im not realising...

[Cyberman]

The save file format for FF8 is somewhat already known.
The characters are encoded in a NON ascii format.
The character encoding for the Japanese version is not known (mutter).
There are bit fields that I have been occassionally working on diciphering.

Etc.  You might wish to use SEARCH here, as there should be several different posts on the data in FF8.
Also you need to keep in mind the CRC calculation.

Cyb

[blipadeebling]

i read that the FF8 save files are compressed, does anyone have any information regarding the compression algorithm used? Thanks.

[Cyberman]

i read that the FF8 save files are compressed, does anyone have any information regarding the compression algorithm used? Thanks.

For the PC they might be though it seems to me very unlikely.
For the playstation they are not, in fact I don't see the point of compressing either for the PC or the PS1.
I believe I left a structure dump of code here a few years back.

There are some important things also, be CERTAIN if you read structures straight from the save file, to have data BYTE aligned, or you will have messy data results.  The size of the save image on the PS1 is 8K in size, (because there are 15 blocks free per 128K flash card and FF8 uses 1 block).
If you have specific questions ask away.

Cyb

[halkun]

not to nitpick, but there are 16 blocks on a memory card (8*16=128) One is reserved for the directory, and the other 15 are game data slots. Just wanted to get that stright in case someone did the math.

[blipadeebling]

Ok well im a bit confused hehe. If the FF8 save file is 8K in size (on the ps version), but after counting the data indicated by the save structure for the PC version found in a post it appears to be be around 8K for a single slot save in the PC version. But the actual file size of these is around 2K (and the size for each slot varies), so i thought that as the post i read said, yeah they have to be compressed (the pc versions at least - havent looked at the ps format as of yet). Also by attempting to follow the structures outlined in in the post manually using a HEX editor, it doesn't seem to match, everything is all messy. This might be a result of not reading as "data BYTE aligned".

Could you please give me a quick description of what this means. Thanks alot.

[Cyberman]

Ummm this has to do with compilors and how data is arranged in the computers internal RAM and access by your program.  It has the potential of making an utter mess if you aren't paying attention to this.  Specifically if you design a structure it's size won't be what you think if you do not byte align the structure.  You will not be able to read data from a file directly into a structure unless you pay attention to the fact that some compilors align the data at different boundry sizes.  The following is an example.

Code: [Select]

struct
{
 unsigned char A, B, C, D;
} Qdata;Each element you might THINK would be right next to the other byte wise. With DWORD (32 bit alignment) it will make the sizeof() this structure 16, whereas with byte aligned it will be 4.  It affects how the data is stored in memory.  So if you read in 4 bytes from a file into a 32 bit aligned structure.  The result would be A would have the data of either A or D, and the other elements would not be filled with the data.  If you read in the data using something like this

Code: [Select]

File.read((char *)&MyData, sizeof(MyData));The result would be reading 16 bytes from the file and various other data pieces being part of A B C and D with the other chunks assigned to oblivion.  Neither case will give you the information you want.  Hence you need to consider data alignment if you do not intend to read then assign each element of the structure individually.

Cyb

[blipadeebling]

Hehe i think im a little bit muddled up because of your post Cyberman, i appreciate it but im having a hard time understanding what you mean. I see that if the data of a structure is "byte aligned" each byte of data takes its appropriate value, but if it was "32-bit aligned" there will be a four-fold increase in the storage space required. Does this apply to say FF8, as the file size is approx. 2K, meaning that the data within the save file is stored in a byte-aligned format, but is read into a 32-bit aligned format, increasing the data size by 4, making it 8K the required size.

If i have said anything correct thatd be good. Could you go into a little more detail about how the data is assigned when say reading that particular structure in a 16-byte format, as opposed to its described 4-byte format? Thanks. (also id appreciate it also if you could please correct me where i said something wrong, thanks again).