Fix JKRArchive on 64-bit

They store the data address in the same struct that's directly loaded from archive files. This means it's impossible to expand to 64-bit directly, and instead we need to allocate the data pointers in a separate array.
This commit is contained in:
PJB3005
2026-02-24 19:55:15 +01:00
parent 4e0a8292e9
commit cf5eca0910
8 changed files with 127 additions and 43 deletions
+24
View File
@@ -51,6 +51,12 @@ inline u16 read_big_endian_u16(void* ptr) {
extern u32 sCurrentDirID__10JKRArchive; // JKRArchive::sCurrentDirID
#if TARGET_PC
#define JKAR_DATA(entry) getFileDataPointer(entry->index)
#else
#define JKAR_DATA(entry) entry->data
#endif
/**
* @ingroup jsystem-jkernel
*
@@ -78,7 +84,16 @@ public:
BE(u32) type_flags_and_name_offset;
BE(u32) data_offset;
BE(u32) data_size;
#if TARGET_PC
// Yes, they store the data pointer in the datastructure that's directly loaded from
// archive files.
// We can't expand this struct to fit a 64-bit pointer, so instead
// we'll need to store this data in a separate array.
// Store the *index* of this entry (!= file_id), so we can look up the real pointer easily.
u32 index;
#else
void* data;
#endif
u32 getNameOffset() const { return type_flags_and_name_offset & 0xFFFFFF; }
u16 getNameHash() const { return name_hash; }
@@ -131,6 +146,11 @@ protected:
JKRArchive();
JKRArchive(s32, EMountMode);
#if TARGET_PC
void*& getFileDataPointer(int idx) const;
void initFileDataPointers();
#endif
public:
bool getDirEntry(SDirEntry*, u32) const;
void* getIdxResource(u32);
@@ -189,6 +209,10 @@ public:
/* 0x50 */ s32* mExpandedSize;
/* 0x54 */ const char* mStringTable;
#if TARGET_PC
void** mFileData;
#endif
protected:
/* 0x58 */ u32 field_0x58;
/* 0x5C */ JKRCompression mCompression;
+1 -1
View File
@@ -28,7 +28,7 @@ public:
private:
/* 0x00 */ // vtable
/* 0x04 */ // JKRArchive
/* 0x64 */ int field_0x64;
/* 0x64 */ intptr_t field_0x64;
/* 0x68 */ JKRAramBlock* mAramPart;
/* 0x6C */ int field_0x6c;
/* 0x70 */ JKRDvdFile* mDvdFile;