Decompiled Format Overview

Post Reply
User avatar
JacksonCougar
Huurcat
Posts: 2460
Joined: Thu Dec 06, 2007 11:30 pm
Location: Somewhere in Canada

Decompiled Format Overview

Post by JacksonCougar »

The decompiler currently follows this naming scheme:
filename.class.file_type.ext

The reason I have for not making the file_type token the file-extension is pretty simple: usability. I would rather just have all plain text files saved with a .xml extension so that they can be easily viewed in a text-viewer by default (the data is xml anyways).

So currently I have two file-extensions in use: .xml and .bin.

The current file_type tokens that I use are tag_blocks (for meta), raw_blocks (for raw binary), and string_references (special Unicode file, decompiled from unic tags).

I will be storing no extra information in the decompiled state: filenames will be given by the folder hierarchy, and tag_block files are parsed such that their pointers are converted to local file-offsets, and their raw pointers are converted to a local offset in the matching raw_blocks file (or left as external pointers). Unicode tables are decompiled back into unic tags, with the Unicode data being stored in an xml file.

Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.
User avatar
XZodia
Staff
Posts: 2208
Joined: Sun Dec 09, 2007 2:09 pm
Location: UK
Contact:

Re: Decompiled Format Overview

Post by XZodia »

JacksonCougar wrote:Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.
I'm not sure I full understand what you mean by this but it doesn't sound like a good idea...
Image
JacksonCougar wrote:I find you usually have great ideas.
JacksonCougar wrote:Ah fuck. Why must you always be right? Why.
User avatar
JacksonCougar
Huurcat
Posts: 2460
Joined: Thu Dec 06, 2007 11:30 pm
Location: Somewhere in Canada

Re: Decompiled Format Overview

Post by JacksonCougar »

After talking to Xzodia about it and seeing the merits of doing so I am going to decompile the tag's into a single file. The file format I have in mind looks like this:

Code: Select all

class TagFile
    {
        int TagBlocksOffset;
        int TagBlocksSize;
        int RawBlocksOffset;
        int RawBlocksSize;
        int StringReferencesCount;
        int StringReferencesIndexOffset;
        int StringReferencesTableOffset;
        int StringReferencesTableSize;
        int StringIDCount;
        int StringIDIndexOffset;
        int StringIDTableOffset;
        int StringIDTableSize;
        int TagIDCount;
        int TagIDIndexOffset;
        int TagIDTableOffset;
        int TagIDTableSize;

        struct StringReferences
        {
            StringID Name;
            string[] EnglishStrings;
            string[] JapaneseStrings;
            string[] FrenchStrings;
            string[] GermanStrings;
            string[] ItalianStrings;
            string[] SpanishStrings;
            string[] KoreanStrings;
            string[] ChineseStrings;
        }

        //StringID Table & Index will work the same as in the map file

        //TagID Table and Index
        //Index point to start offset of Filename string
        //Table is a list of null terminated strings.
    }
Post Reply