64bit values are read using 2 32bit Reads

[LWSS]

https://github.com/XboxChaos/Assembly/blob/master/src/Blamite/IO/EndianReader.cs#L152

[0xdeafcafe]

How so? It just reads two UInt32's then does the endian swap if needed

[0xdeafcafe]

Closing as this is intended behaviour. If you think something is wrong please post and comment and I'll reopen.

[LWSS]

put breakpoints on rpm/wpm and you'll see why people complain about their patches taking 10+ minutes to load. The program is a mess and I just commented about one instance that I found of it being slow.

[adierking]

Yeah, doing two reads to read a 64-bit value isn't great.

[LWSS]

reading the strings 1 byte at a time is probably the worst thing.

I would like to point out that most of the time the strings will have a max size and you can just read in the chunk of memory.

Here's an example of part my mapheader for reach mcc

    void* virtualBaseAddress_toMetaArea; //0x0000
    char pad_0008[8]; //0x0008
    uint32_t header; //0x0010 -- 'daeh' or 0x68656164
    int32_t version; //0x0014
    uint64_t fileSize; //0x0018
    IndexHeader* indexHeader; //0x0020
    uint32_t tagBufferOffset; //0x0028
    uint32_t virtualSize; //0x002C
    char mapName[256]; //0x0030  <-------------------------
    char engineBuildDate[32]; //0x0130  <-------------------------
    MapFileType mapFileType; //0x0150
    char pad_0152[26]; //0x0152
    uint32_t stringDataTableCount; //0x016C
    uint32_t stringDataTableSize; //0x0170
    uint32_t stringIndexTableOffset; //0x0174
    uint32_t stringDataTableOffset; //0x0178
    char pad_017C[44]; //0x017C
    char internalName[36]; //0x01A8  <-------------------------
    char scenarioName[260]; //0x01CC  <-------------------------

[ThunderWaffle]

I'd like to take a look at this at some point. Could you provide a map patch that's slow?