Most Sonic games as of now are 32-bit, and many use 32-bit pointers in their files as well.
HedgeLib++ does direct memory loading, therefore it needs to be able to grab these 32-bit values and use them directly.
Problem is, if you compile HedgeLib++ as 64-bit, most machines will use 64-bit values for pointers. These values are typically in virtual memory space, meaning they're almost always gigantic and simply don't fit within 32-bits at all.
To get around this, HedgeLib++ defines a template struct known as DataOffset32 which contains a single 32-bit data member representing an "offset" from the memory address of this value to the memory address of the value being pointed to.
For example, if you have a DataOffset32 at address 10000000000 pointing to a value at 10000000008, the 32-bit data member held by the DataOffset32 would be 8.
When you dereference a DataOffset32, it simply adds the value of its 32-bit data member (in this case, 8) to its address (in this case, 10000000000) giving the address it's pointing to (in this case, 10000000008).
Alright, so here's the problem:
Try something like this:
StringOffset32 Name = StringOffset32();
Name.Set("Test");
It simply doesn't work.
The address of "Test" is wayyy smaller than the address of Name, to the point where the difference between the two addresses is greater than 0xFFFFFFFF (the maximum value that can be stored within 32 bits).
I believe this is because "Test", in this case, is stored within "static memory space", whereas Name is allocated dynamically?
In any case, it's a huge problem, this problem seems to crop up quite frequently, kind of at random. It's very unreliable, unfortunately. Much more so than I was hoping, anyway.
We need to find another way to somehow get a 64-bit address from a 32-bit value.
All I can think of is to have a static vector of uintptr_ts and use the 32-bit value as an index?
Most Sonic games as of now are 32-bit, and many use 32-bit pointers in their files as well. HedgeLib++ does direct memory loading, therefore it needs to be able to grab these 32-bit values and use them directly.
Problem is, if you compile HedgeLib++ as 64-bit, most machines will use 64-bit values for pointers. These values are typically in virtual memory space, meaning they're almost always gigantic and simply don't fit within 32-bits at all.
To get around this, HedgeLib++ defines a template struct known as DataOffset32 which contains a single 32-bit data member representing an "offset" from the memory address of this value to the memory address of the value being pointed to.
For example, if you have a DataOffset32 at address 10000000000 pointing to a value at 10000000008, the 32-bit data member held by the DataOffset32 would be 8.
When you dereference a DataOffset32, it simply adds the value of its 32-bit data member (in this case, 8) to its address (in this case, 10000000000) giving the address it's pointing to (in this case, 10000000008).
Alright, so here's the problem: Try something like this:
It simply doesn't work. The address of "Test" is wayyy smaller than the address of Name, to the point where the difference between the two addresses is greater than 0xFFFFFFFF (the maximum value that can be stored within 32 bits).
I believe this is because "Test", in this case, is stored within "static memory space", whereas Name is allocated dynamically?
In any case, it's a huge problem, this problem seems to crop up quite frequently, kind of at random. It's very unreliable, unfortunately. Much more so than I was hoping, anyway.
We need to find another way to somehow get a 64-bit address from a 32-bit value.
All I can think of is to have a static vector of uintptr_ts and use the 32-bit value as an index?