Thanks guys, I hope all goes well. The trick with automated test procedures is to try to simulate the kind of situations which tend to cause you problems, minus the time it takes to compile the whole program.
@Dimis
Something smells fishy; a 2048 texture is nothing heavy. You only have two characters on the screen! Run a test program to exclude certain features of the characters to pin point the burden.
Now I have had no luck getting Enhanced Animations to work with my characters, so you are further ahead then I am in Enhanced Animation expertise. But I know a thing or two about textures and shaders. Most likely your graphics card can load textures at 8192 pixels, so 2048 pixel image should be light work. Use the Get Maximum Texture Width()/Height() commands to confirm.
The most memory a 2048 texture can consume is about 16 megabytes. Most of the latest graphics cards have at least 512 megabytes of video RAM; any serious video gamer is going to spare an extra few notes for 1024 megabytes. So loading no more than 20 or 30 of them should be at worst impossible on an old machine, but no big deal on todays hardware. Well, as far as I know, texture size does not consume system RAM whilst running in the 3D simulation. It only consumes RAM
whilst being loaded or manipulated by the CPU; I could be wrong...
Where possible have objects share texture space, delegating image atlas locations for different types of objects; for example a top left part of a texture could be wood, and the bottom could be metal. All metalic and wooden objects could share these textures, reducing the number of load calls, loops, files, texture stages, updates, the list goes on.
As for geometry it is best to avoid loading big .DBO or .X files. Besides stalling the program if you are using a single process, it is a bit messy. The larger the file the more chance you have of data corruption that is difficult to pin point.
As far as I know if you happen to have lots of RAM used up by your program, and you attempt to load big files, the parsing process during the load call might consume more RAM than one realizes. Think of RAM as a number of employees who need to recieve a delivery of goods then present it to the customer. Lots of employees are required to unpack, log, count and put away the stock, but only one needs to present the goods to the customer. If you are limited to a few employees, taking big deliveries creates a backlog, and with memory backlogs leads the crashes.
Break up the world and complex characters into separate objects, then join them by origin, side by side or by adding limbs in code.
I know that CumQuaT already knows this already since his game is contains a huge world. Instance over cloning; where possible vertex repetition over instancing (You can repeat vertices using shaders or vertexdata commands)
With shaders, try to compile them in assembly code where possible using FXC.exe in the DX9 SDK. In the best case scenario these compiled shaders load really fast and consistently. Keep the loops and branch statements to the absolute minimum. It sounds funny but it is true, for every FOR loop or IF statement you write in your shader, you actually increase the chances of it crashing not during gameplay but during the load call! There is a lot of compilation and testing going on during that Load Effect call. You may choose to bypass a number of calculations during the load call with the DoNotGenerateData parameter.
Good luck
