Well if is program is a 32 bit executable, here's your problem. Even if your running on a 64 bits OS, you just can't allocate more than 2 gb of memory. Even with the LARGE ADDRESS AWARE thing, i think you'll be limited to 3gb instead. If you need that much memory, why not compile a 64 bits exec??

yes.

personally though, I am sticking with 32 bits for now, mostly until 32-bit OS's pretty much die off, since a 64-bit program will not work on a 32-bit computer.

I had at one point been building mostly for 64-bits, but this issue of "being friendly to 32-bit WinXP" brought things back.

memory use is still a challenge though, as 2-3GB doesn't go as far sometimes as one might think, and fragmentation can be an issue, especially if one tries to do lots of exact-size arrays.

one trick I have often used is that most variable-size structures (arrays/etc), are not sized exactly, but rather follow a curve like 4*1.5n, or 16*1.5n, such that while there is often a little waste, fragmentation is reduced (when an array is reallocated, it is padded up to the next size in the curve).

this is sometimes combined with a bit of trickery, like some amount of keeping stuff compressed in RAM and decompressing things on demand, ...

interestingly, this turns out to not really be a new thing (it was fairly common back in the 16-bit era).

2-3GB doesn't go as far sometimes as one might think

2-3GB doesn't go as far sometimes as one might think

basically, in my engine, voxel terrain and audio data were eating lots of RAM (previously, the thing kept running out of address space and crashing, but since has been reduced to a more stable 500-700MB, most of the time).

decided to leave out a longer description, but:

voxel terrain can eat lots of RAM (lots of largish 3D arrays of voxels);

to a lesser extent, so can things like PCM audio (at 44.1kHz 16 bit) and compressed video / textures / ...

so, while 2-3GB seems like it should be enough for almost anything "reasonable", it isn't too hard to run into the limit and then sit around trying to shave off memory use to keep everything fitting (or within a more reasonable limit).

basically, keeping voxel chunks, audio, ... compressed until needed, etc.

likewise, a person might need to do things like leave larger video files on disk, and read-in frames individually, rather than just reading the whole video into a memory buffer or put it in an asset pack and bulk-loading it (like one might do for most other asset loading).

for example, while a person might bulk-load their textures and animated textures and sound-effects and similar, they would probably not do so with their cutscenes (which would be left on disk until needed).

also, there may be issues with trying to load or work with very-high-res images (ex: 8192 x 8192 or 16384 x 16384), which may have a hard time fitting in RAM (8192 x 8192 is hit or miss, 16384 x 16384 = no).

basically, in my engine, voxel terrain and audio data were eating lots of RAM (previously, the thing kept running out of address space and crashing, but since has been reduced to a more stable 500-700MB, most of the time).

decided to leave out a longer description, but:

voxel terrain can eat lots of RAM (lots of largish 3D arrays of voxels);

to a lesser extent, so can things like PCM audio (at 44.1kHz 16 bit) and compressed video / textures / ...

so, while 2-3GB seems like it should be enough for almost anything "reasonable", it isn't too hard to run into the limit and then sit around trying to shave off memory use to keep everything fitting (or within a more reasonable limit).

basically, keeping voxel chunks, audio, ... compressed until needed, etc.

likewise, a person might need to do things like leave larger video files on disk, and read-in frames individually, rather than just reading the whole video into a memory buffer or put it in an asset pack and bulk-loading it (like one might do for most other asset loading).

for example, while a person might bulk-load their textures and animated textures and sound-effects and similar, they would probably not do so with their cutscenes (which would be left on disk until needed).

also, there may be issues with trying to load or work with very-high-res images (ex: 8192 x 8192 or 16384 x 16384), which may have a hard time fitting in RAM (8192 x 8192 is hit or miss, 16384 x 16384 = no).

That's like venting the oceans into space and then saying, "We ran out of water because 1,400,000,000,000,000,000,000kg isn't as much as you may think."

basically, in my engine, voxel terrain and audio data were eating lots of RAM (previously, the thing kept running out of address space and crashing, but since has been reduced to a more stable 500-700MB, most of the time).

...

That's like venting the oceans into space and then saying, "We ran out of water because 1,400,000,000,000,000,000,000kg isn't as much as you may think."

granted.

though, for many developers, there is a mindset that RAM is a nearly boundless free resource.

except... when it is not.

like, while big arrays are fairly obvious memory wasters, often lots of memory can still be eaten up by "little things" as well (a buffer here, a buffer there, a few kB here and there, ...), and this may be less obvious.

though, for many developers, there is a mindset that RAM is a nearly boundless free resource.

That's why we should have a government run program that abducts budding programmers and forces them to spend a year developing for old console systems.

though, for many developers, there is a mindset that RAM is a nearly boundless free resource.

That's why we should have a government run program that abducts budding programmers and forces them to spend a year developing for old console systems.

Then they'll start using old console tricks to save memory at the cost of code readability.

Hardware has changed, and with it acceptable use of memory. Budding programmers should learn on today's hardware, with modern and relevant resource considerations.

But it's true enough that no resource is limitless.

Or possibly they'll start using discretion, planning, and responsibility (and maybe learn about portability) instead of using 800MB of memory to run a calculator. My point is not just that resources are limited. My point is that consuming resources simply because they're available is disrespectful to the end user who had to pay money to buy those resources so that they would have more available. There's no reason (apart from laziness) for a program to consume more than it's using, and it tends to lead to bad design habits, such as the ubiquitous 'load everything now' screen.