ericbabe
Posts: 11927
Joined: 3/23/2005 Status: offline
|
quote:
ORIGINAL: Wellesley I.e.: you don't know why it is happening then. Hm. I'm quite surprised to hear that it could be a memory problem... Some of the most top-heavy 3D-games run smoothly on this rig but CoG can't? That's odd. Is the compiling how you'd like it? I don't know why it is happening. It is often difficult to diagnose technical computer problems without knowing all of the necessary details. We've never had anyone reporting a crash-to-display that happened in this manner before. I can run COG on a machine with only 128MB, though with heavy virtual memory caching, so it does run on low-memory systems. However, I've found that the stability of virtual memory varies from system to system, being heavily dependent upon other applications that might be resident in memory. COG uses a lot of RAM, but does not use much video card memory, so it isn't directly comparable to the sort of 3D games you mention, which typically are more dependent upon the video card for their performance and for the storage of their textures. It actually takes much less RAM to store a 3D object and its textures than it does to store a series of video sprites that represent a 3D object. The double sound devices that Erik found in your DxDiagnostic could possible be causing this problem. The Windows 2K machine we test on had a GPF problem when I had both the Sound Blaster device and the motherboard's sound card both activated, though in that case it crashed as soon as the sound file data was initiated. I'm not sure whether a sound card conflict would cause heavy drive caching -- you could perhaps check your Performance Monitor and see whether the drive access you report before a crash is simply just drive access or whether it is actual VM caching. I compile the program using the standard Microsoft run-time libraries using optimizations for speed (in some places) and size (in other places). I'm not sure why you ask. Do you have any compiler options in mind that you think we ought to be using? The actual executable file is very small, only a few MB's -- the vast majority of the RAM used by COG is dynamically allocated to hold the graphics and sound data -- and compiler options won't affect this, excepting perhaps for quad byte alignment, which we do use, as this greatly enhances the speed of the application.
|