I was helped in my quest by a tool called VMMap which does a splendid job of illustrating where ALL the system memory is being spent. Even things you have no control over are displayed, and from this information I was able to make some good savings.
Once such site of squander was the inclusion of an old DBP DLL called ConvMDL which was once used to load MDL files (from the old Quake days). This innocuous DLL was eating 125MB of static memory until I excluded it from all further action in this project, along with support for 3DS, MD2 and MD3 :) Other savings (and performance boosts) were found in in the terrain visual and collision systems which together gobbled over 600MB (now more like 300MB). I dare say more savings can be found but right now it's about overall stability, and if the engine can now run on 32 bit machines without having to reset every five minutes then I will be a happy chappy.
I have noticed my 'super terrain texture' generator eating 80MB of system memory which in fact it's job is to produce a GPU video memory texture, so that's something to investigate tomorrow me thinks. Hopefully as more system memory is rescued, the engine will gain more stability and longer term will allow MUCH larger levels to be created without worrying about the dreaded red screen of death.
It's not all plane sailing though, in making my massive cut backs, my pre-baked terrain shadows have gone walkabout so Tuesday will involve a hunt for these pesky shadows and to put them back!
That module was eating up that much memory? Wow! The version of that module that I got a hold of (from the repository) was extremely slow too, due to repeated use of the strcat() command. I redid that portion of the code to eliminate strcat(), and it's much faster now. Never came across (or noticed) a memory issue like that though.
ReplyDeleteThe public DBPro repository - that is.
Delete