Hey,

I'm following the stream on Youtube and I'm quite far behind with day 15. I'm a physics student, which means I'm not a developer - so bear with me. :)

On day 14 (I think) Casey wrote the VirtualAlloc with TransientStorage and PermanentStorage and set the size to 4Gb. I did that too, but the allocation used to fail with that much memory. (I'm working on a 64bit Win7 Laptop with 4Gb of RAM..)

So I reduced it to 3Gb and it works most of the time? Why is that?

I mean it allocates virtual memory, which is not physical memory but looks like real memory as far as my process/game is concerned. (Casey talked about that the OS does all that in the background)
So why when I use VisualStudio to debug, the Game exits because I dont get enough memory and literally seconds after that I restart it and it gets the 3Gb?

Ps: And why does Casey have a -DHANDMADE_WIN32=1 in his build script? I somehow missed why this is defined in the source code..
(I only use the -DHANDMADE_INTERNAL=1 -DHANDMADE_SLOW=1)

That's the difference between reserving memory and committing it. Reserving with MEM_RESERVE just earmarks a chunk of the process's virtual memory space without actually backing it with physical memory. This can rarely fail, usually only when you try to reserve the same piece of memory twice. Committing memory with MEM_COMMIT asks the OS to go out and grab some physical memory, which obviously requires enough of it to be available.

I'm not sure why committing 3GB would sometimes work and sometimes won't for you. My guess would be that 3GB is close to the free memory after accounting for the OS and other processes running on your system, and some application temporarily uses a bit more memory, dropping your free space below 3GB.

DomsL.

I had the same issue on that day.
After I closed some other programs that were using memory, then VirtualAlloc worked every time.
It seems that Virtual allow will fail if you don't have enough free memory.
But don't worry about it too much, for now you can just reduce it to something that works for you for now.

I reduced it to 1Gb now and sometimes it still doesnt work the first few times. Then all of a sudden it could get the memory.
So maybe there is a thing in Windows which is starting to free up memory, if a VirtualAlloc fails for a couple of times?

Thanks for your answears, maybe I will have to read up on the subject.

Casey mentions on day 24 that virtualAlloc memory is always contiguous.
I'm guessing, but maybe virtualAlloc is sometimes not able to get a large enough contiguous block to allocate?

On a 4Gb 64 bit win 7 laptop as well, and my limit is around the 1Gb mark (to be safe am now only using 128 MB).

I figured I'd have to get more ram once we started actually needing the memory in-game, but maybe this is the excuse I've been waiting for to build a proper desktop workstation instead...

This is slightly worrisome because this limitation is not only hit during development but end-users will hit it too. Of course the size of the memory pool should be trimmed to what's actually needed, which will (probably) help a bit..

I haven't looked at the virtualAlloc call's parameters to see whether this can be tweaked, but it's odd that it's failing. We're not requesting actual contiguous physical memory range, are we? The MMU should be able to make anything contiguous.. this is *virtual* alloc after all.

..

From a quick glance, my guess is that the failure is due to something having already been mapped to the memory range we're requesting. How to avoid that is a good question..

I have had the same thing today. It started on day 16.
I have 16g ram, about 4g is in use. And my HD has 30g free.
I changed:



to:



and it works fine now.