Hi All, I'm new to HH and the forum (and to C!).
This may have previously been answered but I can't find it.
On Day 023 the point was made that the looped live code only worked because we had a fixed virtual base address (2TB) as below:
I'm struggling to understand why - given that the VirtualAlloc will return the address to the Win32State regardless:
So it would seem the game DLL when loaded would always get a correct pointer to this base address despite the fact that the address may vary each time the game is started. The same would go for the writing and reading of the memory block to disk.
I understand that if a pointer was referencing a particular memory location and the contents moved to a different location that this would break the code - but I can't see how this happens?
I'm sure I'm missing something so any comments or examples would be great.
Thanks everyone.
Ben
This may have previously been answered but I can't find it.
On Day 023 the point was made that the looped live code only worked because we had a fixed virtual base address (2TB) as below:
1 2 3 4 5 | #if HANDMADE_INTERNAL
LPVOID BaseAddress = (LPVOID)Terabytes(2);
#else
LPVOID BaseAddress = 0;
#endif
|
I'm struggling to understand why - given that the VirtualAlloc will return the address to the Win32State regardless:
1 2 | Win32State.GameMemoryBlock = VirtualAlloc(BaseAddress, (size_t)Win32State.TotalSize,
MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);
|
So it would seem the game DLL when loaded would always get a correct pointer to this base address despite the fact that the address may vary each time the game is started. The same would go for the writing and reading of the memory block to disk.
I understand that if a pointer was referencing a particular memory location and the contents moved to a different location that this would break the code - but I can't see how this happens?
I'm sure I'm missing something so any comments or examples would be great.
Thanks everyone.
Ben
The real reason is to get consistent pointer values each time the game is restarted.
This helps a lot when debugging as you can put the (casted) pointer in the watch window and get the same object back after restarting.
This helps a lot when debugging as you can put the (casted) pointer in the watch window and get the same object back after restarting.
Thanks for the reply!
I understand that this is a good reason to use the fixed base and that the looped debugging in the watch window would be pretty painful otherwise.
Do you know of any reason that the day 023 code wouldn't actually run properly without the fixed base assigned in the win32 layer?
Cheers
Ben
Ben J Anderson
Thanks for the reply!
I understand that this is a good reason to use the fixed base and that the looped debugging in the watch window would be pretty painful otherwise.
Do you know of any reason that the day 023 code wouldn't actually run properly without the fixed base assigned in the win32 layer?
Cheers
Ben
there isn't any, the define is bracketed in a #ifdef so that the release build sets it to 0 (aka let the OS pick its own base address).
It's also because the looped live code, writes the memory to disk (the first frame of the recording) and the inputs (for all frame that are recorded) so you can play it back after restarting the application.
If in the memory written to disk you have a pointer, it contains the actual virtual memory address from that run of the program, not an offset from the base address (returned from VirtualAlloc). If on the next run of the program, you don't allocate the memory at the exact same place, and load the memory image from disk, the pointer might point to an address that is outside the current program address space.
If you never load the memory from disk on different runs of the program, I doesn't really matters.
If in the memory written to disk you have a pointer, it contains the actual virtual memory address from that run of the program, not an offset from the base address (returned from VirtualAlloc). If on the next run of the program, you don't allocate the memory at the exact same place, and load the memory image from disk, the pointer might point to an address that is outside the current program address space.
If you never load the memory from disk on different runs of the program, I doesn't really matters.
Thank you!
That's what I thought could happen. However correct me if I'm wrong, but since the Base Address is resolved in the Win32 layer upon startup it doesn't change through the life of the run?
My understanding is that you could:
1) dump the game memory block to disk,
2) update and reload the Game DLL,
3) restore the game memory block from disk
and all would be ok as you have not altered the base address in the Win32 layer (so the pointer saved to disk would still be valid)?
I would have thought only doing a new non-fixed VirtualAlloc after doing the dump would cause issues? And in the day 023 code we do the alloc at the start and it never changes (no matter how many times we reload the dll).
Is my logic above valid?
Thanks again,
Ben
Ben J Anderson
I would have thought only doing a new non-fixed VirtualAlloc after doing the dump would cause issues? And in the day 023 code we do the alloc at the start and it never changes (no matter how many times we reload the dll).
the non-fixed VirtualAlloc would cause issues if you quit and restart the game and then loaded the memory dump from disk
@Ben J Anderson : you're correct.
To summarize:
- In a single run of the program you never want to change the base address, as the memory dump contains pointers that are only valid in the original region of memory.
- In a single run of the program it doesn't matter if you specify a base address or not.
- In multiple runs of the program, the base address needs to be the same if you want to load the memory dump from a previous execution of the program.
To summarize:
- In a single run of the program you never want to change the base address, as the memory dump contains pointers that are only valid in the original region of memory.
- In a single run of the program it doesn't matter if you specify a base address or not.
- In multiple runs of the program, the base address needs to be the same if you want to load the memory dump from a previous execution of the program.
ratchetfreak, mrmixer
Thanks so much for taking the time and sharing your knowledge on this.
Ben