Owen said:
Sorry Castellon, I did that over a year ago just to get in quicker. Personally, I don't believe renaming the avi folder is quite the panacea you think it is.
How is it that renaming the avi folder can have any effect on crashing once the game is fully loaded?
It can, if the BinkPlayer used in the cinematics doesn't release all resources (DirectX or Win API) it has claimed. Win9X has a very, very limited amount of memory reserved (2 * 64 KB, and this is fixed) for all system related resources like mouse arrows, menu bars, window handles, etc. If this area fills up, then Windows API calls will start to fail, and most applications (especially Microsoft ones, or applications generated with Microsoft tools) will behave erraticly or even crash. This is, for example, why you cannot run MS Word or MS Excel for long periods of time on a Win9X based system. Especially Excel leaks like crazy.
Now, how can the resource memory area become full? Two reasons. The first and obvious one is when you run too many resource hungry applications concurrently. Secondly, one of the apps leaks resources. In other words, resources get created/allocated without getting freed. This too is a serious problem on win9x, as win9x doesn't contain a robust resource garbage collector to clean up the mess, created by sloppy programmers and/or library packages. Win2K OTOH does, which is why leaking resources on a Win2K platform doesn't have the nasty consequences it has on win9x based systems, even though applications would enjoy speed benefits if they would not leak. Mind you, eventually Win2K
will start to fail if a leaking app is run continously. Leaked resources will take up memory, and sooner or later the swap file is filled up to the max. Then the app will start to behave erraticly on Win2K systems as well.
Having said all this, I do believe the ultimate problem is within EU2 itself (and it's probably a resource leak) as I get slammed with this problem with long EU2 play sessions, and not with short ones. What probably happens is that for some DirectX related calls some defaults are assumed that, through the drivers, are true for most systems. One some systems (mine included) these default assumptions are probably not true, and hence the failures. This problem will most likely go away if all calls have all their initialisations explicit, so there is no reliance on (driver supplied) defaults, and each resource acquisition is followed by an explicit call to release that resource.
Mind you, it is very easy to mess up in this area without even knowing it. I've had a similar experience when a wrote the library code that takes care of print jobs for our applications. Initially I setup the Device Context once, after creating the print job. And for our HP laser printers with HP drivers, that was fine. These drives automatically carry the device context initialisations over from page to page. However, other brand drivers didn't do that, and thus only page 1 of a job got printed correctly. For those drivers, the programmer was appearantly responsible for re-initialising the device context for every new page of the print job. And, worst of all, this isn't documented anywhere. So, if a programmer only works with HP laserprinters, he would never know he was relying on default vendor specific behaviour instead of documented Windows standardised behaviour.
Jan Peter
