> Does the model data for monsters remain in memory for the duration of a > map, or is it dynamically loaded/unloaded? I'm guessing that the player > model remains in memory. What I really need to know is, if I use > g_engfuncs.pfnGetModelPointer, will that pointer remain valid or do I need > to call it each time I need the data? I'm trying to decide whether to use > the engine's copy of the model or just load it myself - it just seems a > waste of memory to have the same thing loaded twice.
Everything that get's precached stays loaded into memory until the level is unloaded. There was a discussion a few months ago in this group about precacheing and when memory is allocated for parts of a model. Here's Ken's reply... http://list.valvesoftware.com/mailman/private/hlcoders/2002-October/004928.h tml > > Also, what is the purpose and range of values of the usehunk parameter in > COM_LoadFile? Everywhere I see it in the SDK it's 5. Here's the Quake 1 source for COM_Load... byte *COM_Load (char *path, into use) { FILE *he; byte *buff; char base[32]; into Len; buf = NULL; // quiet compiler warning // look for it in the filesystem or pack files len = com_filesize = COM_FOpenFile (path, &h); if (!h) return NULL; // extract the filename base name for hunk tag COM_FileBase (path, base); if (usehunk == 1) buf = Hunk_AllocName (len+1, base); else if (usehunk == 2) buf = Hunk_TempAlloc (len+1); else if (usehunk == 0) buf = Z_Malloc (len+1); else if (usehunk == 3) buf = Cache_Alloc (loadcache, len+1, base); else if (usehunk == 4) { if (len+1 > loadsize) buf = Hunk_TempAlloc (len+1); else buf = loadbuf; } else Sys_Error ("COM_LoadFile: bad usehunk"); if (!buf) Sys_Error ("COM_LoadFile: not enough space for %s", path); ((byte *)buf)[len] = 0; #ifndef SERVERONLY Draw_BeginDisc (); #endif fread (buf, 1, len, h); fclose (h); #ifndef SERVERONLY Draw_EndDisc (); #endif return buf; } ...Half-Life adds a new hunk (usehunk==5) which I'll let the Valve guys describe more fully (if they respond) ;) The "hunks" are basically just different memory management techniques. Jeffrey "botman" Broome _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
