Func_Msgboard: General Abuse

#32159 posted by mh on 2022/06/28 17:32:14

Quake's memory management is designed around running on an MS-DOS PC with 8 MB of memory and no virtual memory.

That's why it does things like having a fixed-size hunk, allocating the zone from that hunk, and allocating models and other objects in a cache that things can be moved into and out of on-demand, also from that hunk.

That's why software Quake also allocates it's video buffers from the same hunk.

The main constraint here is that 8 MB is an absolute hard limit. The program just cannot go above it, unused pages won't get swapped out (no virtual memory), and this limit is enforced by allocating all memory that the program is going to use at initialization time. There's some looseness for temp buffers and the stack, but otherwise any attempt to use more memory will be a crash.

WinQuake and GLQuake were obviously quick and dirty ports that didn't have the same constraint, so they sometimes go into alternative memory management and usage via big static buffers, etc.

It's very instructive to look at how memory management changed between Quake 1 and Quake 2. Quake 2 did not run on DOS, so it could take advantage of running on an OS that managed virtual memory for it, and all of the cache stuff was gone, the Zone was just replaced with malloc calls (and some tags to allow for multiple zones), and instead of a single large global hunk, each model had it's own individual hunk.

The memory management stuff I did on the old Inside 3D just replaced the Zone with malloc, on the basis that there was only one zone in Quake 1. It also replaced the cache with malloc, so that sounds, models and other items are never actually evicted from the cache, but instead persist for the entire run of the program.

That approach is obviously not compatible with game changing, nor with anything like Frik File (IIRC) that needs multiple Zones, but it was never meant to be, and further enhancements are left as an exercise to each individual.