Handmade Hero » Forums » Code » Day 023 Looped Live Code- use of fixed base address for game memory
Ben J Anderson
Ben Anderson
4 posts
#10957 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

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:

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


ratchetfreak
237 posts
#10958 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

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.
Ben J Anderson
Ben Anderson
4 posts
#10959 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago


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
ratchetfreak
237 posts
#10960 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

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).
mrmixer
Simon Anciaux
176 posts
#10961 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

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.
Ben J Anderson
Ben Anderson
4 posts
#10962 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago


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

ratchetfreak
237 posts
#10963 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

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
mrmixer
Simon Anciaux
176 posts
#10966 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago

@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.
Ben J Anderson
Ben Anderson
4 posts
#10974 Day 023 Looped Live Code- use of fixed base address for game memory
1 month ago


ratchetfreak, mrmixer

Thanks so much for taking the time and sharing your knowledge on this.

Ben