Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reversed exploded package file header #29

Open
Zekfad opened this issue Mar 27, 2024 · 4 comments
Open

Reversed exploded package file header #29

Zekfad opened this issue Mar 27, 2024 · 4 comments

Comments

@Zekfad
Copy link

Zekfad commented Mar 27, 2024

Seems that bitsquid (stingray) partially moved to 64bit offsets and header includes some clues for read buffers
E.g. aligned offsets seems to suggest that during load they allocate full buffer size or smth like that.
Here's file header as I see it:

    struct file_header_t {
        le hash::hash_name name;
        le hash::file_type type;
        
        // aligned to alignment
        le u64 offset;
        // unaligned raw aux buffer
        le u64 stream_offset;
        // aligned to gpu_alignment
        le u64 gpu_offset;
        
        // aligned to 0x200
        // seems to be an offset of read buffer that have size of 0x200 per element
        le u64 buffer_offset;
        // aligned to 0x600
        // seems to be an offset of read buffer that have size of 0x600 per element
        le u64 gpu_buffer_offset;
        
        le u32 size;
        le u32 stream_size;
        le u32 gpu_stream_size;
        
        le u32 alignment;
        le u32 gpu_alignment;
        le u32 index;
        
        file_t<size> inline_file @ offset;
    };
@Xaymar
Copy link
Owner

Xaymar commented Apr 12, 2024

Has there been an update to the package/data structure? There's a few entries missing between gpu_offset and size, which would make the new structure smaller than before. Edit: Nevermind, I did not see the "buffer" part of the variable.

@Xaymar
Copy link
Owner

Xaymar commented Apr 12, 2024

It seems to be a better match than the original structure. While I don't know what the two other offsets would be used for - too far from the actual data to be of use to anything - everything aligns well and it does remove the unknowns. Plus if the game ever decides to go above 4GB for a single file, it'll be supported now.

@xypwn
Copy link
Contributor

xypwn commented Apr 12, 2024

The type header seems to also have the alignment and gpu_alignment fields at the end, since they always have the same set of values.
EDIT: Although I don't really understand how a type having an alignment would make sense if the file itself already has an alignment.

@Zekfad
Copy link
Author

Zekfad commented Apr 12, 2024

buffer offsets seems to be related to how game read files.
If my understanding is correct internal structure have a known size, some array is allocated and then files are read (mapped?) to array elements. e.g. buffer_offset seems to be aligned to 0x200 bytes per element

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants