So I've been working with the day 30 code for a few days now, but all of a sudden
LPVOID BaseAddress = (LPVOID)Terabytes(2);
is setting BaseAddress to 0x00000000, which is setting Win32State.GameMemoryBlock to 0x00000000 during the VirtualAlloc call, which is setting GameMemory.PermanentStorage to 0x00000000 resulting in the if(Samples && GameMemory.PermanentStorage && GameMemory.TransientStorage) check failing. Maybe this is what these values were getting set to before, but I wasn't looking at them. I do know that it was working before and has since stopped.
I was wondering if there was something maybe that I did to cause this to stop working or if anyone has an answer for what's going on and what I can do to fix it.
LPVOID BaseAddress = (LPVOID)Terabytes(2);
is setting BaseAddress to 0x00000000, which is setting Win32State.GameMemoryBlock to 0x00000000 during the VirtualAlloc call, which is setting GameMemory.PermanentStorage to 0x00000000 resulting in the if(Samples && GameMemory.PermanentStorage && GameMemory.TransientStorage) check failing. Maybe this is what these values were getting set to before, but I wasn't looking at them. I do know that it was working before and has since stopped.
I was wondering if there was something maybe that I did to cause this to stop working or if anyone has an answer for what's going on and what I can do to fix it.
If you see value of BaseAddress as 0x00000000 that means you are compiling code as 32-bit. 32-bit code can have only 4GB of virtual space - 32-bit pointer can address bytes only from 0 to 2^32. 2 terabytes is 2*1024*1024*1024*1024 = 2^41. Taking lowest 32 bits from 2^41 gives you exactly 0:
Casey is currently writing code with assumption you will be running it as 64-bit. It simplifies a lot of things during development. And that is reasonable assumption because any desktop CPU from last 10 years (or so) is 64-bit.
If you want to compile code as 32-bit, you'll need to adjust this part of code. If you are OK to loose live edit/reload feature you can simply set BaseAddress to 0. That is what game will pretty much do when it will be released (no reason to live edit code) - OS will choose whatever address is free.
Or you can try to find some address where virtual memory can be allocated. Try something from 0 to 2nd GB. Note that this range can be pretty fragmented - any system dll loaded will take space, any memory allocated by startup code for these dlls will take some space, memory allocated by C runtime will take space. Anything up from 2nd GB is reserved for kernel by default. There is linker flag that will reserve only range from 3rd to 4th GB leaving lowest 3GB for application. By default it is not enabled for 32-bit code: https://msdn.microsoft.com/en-us/library/wz223b1z.aspx
1 2 3 | 2^41 = 100000000000000000000000000000000000000000
2^32 = 1000000000000000000000000000000
****************************** --> only these bits fit in 32-bit register
|
Casey is currently writing code with assumption you will be running it as 64-bit. It simplifies a lot of things during development. And that is reasonable assumption because any desktop CPU from last 10 years (or so) is 64-bit.
If you want to compile code as 32-bit, you'll need to adjust this part of code. If you are OK to loose live edit/reload feature you can simply set BaseAddress to 0. That is what game will pretty much do when it will be released (no reason to live edit code) - OS will choose whatever address is free.
Or you can try to find some address where virtual memory can be allocated. Try something from 0 to 2nd GB. Note that this range can be pretty fragmented - any system dll loaded will take space, any memory allocated by startup code for these dlls will take some space, memory allocated by C runtime will take space. Anything up from 2nd GB is reserved for kernel by default. There is linker flag that will reserve only range from 3rd to 4th GB leaving lowest 3GB for application. By default it is not enabled for 32-bit code: https://msdn.microsoft.com/en-us/library/wz223b1z.aspx
Edited by Mārtiņš Možeiko
on
Are you actually compiling for 32 bit?
I ask because I have been doing this. If so, then you should have encountered a problem before day 30. IIRC, the virtual allocation has been over 4 Gb almost from the start. If you were compiling for 32 bit you would have been changing this all along. If you haven't then I am wondering if you are hitting a different issue.
VirtualAlloc can fail and it will return 0. You should check GetlastError immediately in that case to be sure.
- tim
I ask because I have been doing this. If so, then you should have encountered a problem before day 30. IIRC, the virtual allocation has been over 4 Gb almost from the start. If you were compiling for 32 bit you would have been changing this all along. If you haven't then I am wondering if you are hitting a different issue.
VirtualAlloc can fail and it will return 0. You should check GetlastError immediately in that case to be sure.
- tim