Introduction
I think that a lot of people have discovered by now that some of the new maps included with Desert Combat Final (an updated mod for Battlefield 1942) can become rather choppy during online game play. When I ran into this, I noticed that my hard drive was active during these periods of stuttering; so, I guessed that with only 512 MB of system memory, my computer was having to make use of the windows swap file to run the game. This hunch was reinforced by remembering that people complained of similar problems when Battlefield Vietnam came out and that the general recommendation was to increase your system memory to 1 gigabyte, if you had less than that.
I decided to put this idea to the test and ordered another 512 MB of RAM for my system. In the meanwhile, I was curious to see what was happening with my system as it struggled to run the game. So, I made use of some diagnostic tools that are part of Nvidia's video drivers and some others that are included with Windows XP to see if these would support my ideas about what was going on.
[Just a quick description of the system I'm using, it is an Athlon XP mobile processor clocked at 2300 MHz (which is a little faster than a standard Athlon XP 3200); it uses an Asus Ti4200 video card clocked at the same speed as a Ti4600 (300 MHz core and 650 MHz memory); the memory is Mushkin PC3500 Level One, using one 512 MB module for the first set of tests and then two 512 MB modules (in dual channel mode) for the comparison; the operating system is Windows XP Pro; and the video drivers are Nvidia's 56.72 version.]
NVIDIA's Performance Graph
If you are running a recent version of Nvidia's Windows XP display drivers, it includes a Performance Graph, which you can access under "More Direct 3D" options.
If you don't see this option with your drivers, you might need to enable this feature with the "coolbits" registry hack (just as you do the overclocking option), as seen below. As far as I know, this Performance Graph only is available in the Windows XP drivers, not the Windows 98 drivers.
Once you've enabled the Performance Graph, next time you start up your favorite game, you'll be presented with something like this.
The above screenshot is taken from the Aquamark 3 benchmark. Starting from the bottom right-hand corner, we see a kind of bar graph that indicates how much AGP system memory is being used (which is nearly none, as indicated by the little blue line); next, we see how much video card memory is being used (which is about 32 MB in this case); and then, we see a graph with three lines. The yellow line depicts the frame rate in terms of milliseconds per frame. It looks like we're averaging about 37 ms per frame, which translates to about 27 frames per second. Just below this is a blue line, which indicates how much the CPU is left waiting for the video card while both go about their business of processing the game's graphics data. In the above scene, my Ti4200 video card is clearly the bottleneck, as it is leaving the CPU waiting. The straight red line at the bottom has to do with how long it takes the CPU to do its share of the graphics processing. In this case, we see that it is not holding things up at all. Above this first graph is another that depicts the number of batches being used. I'll have to let the "Geforce FX Programming Guide" explain this one.
"Batching” refers to grouping geometry together so several triangles can be drawn with one API call, instead of using one API call per-triangle. There is some driver overhead whenever you draw geometry, and the best way to amortize this overhead is to draw several thousand triangles at once. Therefore, using a smaller number of larger batches is a great way to improve performance.
So, as the complexity of the scene increases to the point that the number of batches becoms high, we can expect to see the frame rate start to go down (or more exactly, in these graphs, the time per frame will go up). This trend can be seen in the Desert Combat scene, below.
Battlezone II is a game that tends to be very CPU dependent. For one thing, it makes use of a lot of lighting effects, but the game was written before there were graphics cards that could easily handle these features in hardware. Consequently, a fair share of the graphics rendering work falls to the CPU to take care of.
In contrast to our Aquamark 3 scene, here we see how that the red line, for time spent in the driver, has gone up, but not the blue depicting that the CPU waiting for the GPU. As the gun towers light things up with their cannon fire, the load on the CPU increases and we see how the driver time graph jumps up a bit. This is matched by a jump in the time per frame, as well. This indicates that it is how quickly our CPU can do its processing that is determining how fast the graphics card can pump the frames out in this situation.
Windows XP's Performance Tools
If you drill down through Control Panel, Administrative Tools, and hit the Performance shortcut, you'll find Windows XP's System Monitor. This tool is something like the System Monitor that is available in Windows 98.
Above, you see the default configuration for the System Monitor, but there are dozens of other items that you can track.
Since I am particularly interested in memory usage, including the swap file, I wanted to examine these four areas: physical memory used, swap file used, page faults, and hard disk activity. In order to observe these factors, I set up four graphs, one for each of these items, and spread them around on my desktop, while I ran Desert Combat in a window. (Since the following screenshots are of my desktop at 1024x768 resolution, they will most easily be viewed at that resolution.)
Playing Desert Combat Final with 512MB of RAM
The above picture shows the situation as the game loads up the level I'm about to enter. Looking at the lower left graph, we can see that the game has quickly gobbled all available RAM. Looking at the next, lower right graph, we can see that the hard drive is staying busy at this point. And, looking to the graph above that one, we can see that the percentage of my swap file being used is gradually increasing. I have a fixed swap file size of 1532 MB; so 13.4% of that is about 205 MB of swap file usage. As the level loads, there are a lot of page faults as well.
Although I won't have a lot to say about these, the page fault graph also tracks what are called transitional page faults, as shown by the light yellow line. These are a subset of the total number of page faults, and they are made up of page faults that typically don't result in any disk activity. Consequently, these are also referred to as soft faults. The swap file usage graph also includes a second line, the thinner red one, which shows the peak swap file usage since the time the data recording was started. The Average, Minimum, and Maximum readings for each graph only include the period of time shown on the graph, which is for the last 100 seconds. The vertical red line sweeps across from left to right, drawing the new graph data as it goes.
[In the following screenshots, Desert Combat is being played, online, in a 640x480x32@85Hz window. The in-game graphics options are all enabled and set to their highest settings. You can enable this ability to play the game in a windowed mode by changing a setting in your VideoDefault.con file. Look for this file down this path: C:\Program Files\EA GAMES\Battlefield 1942\Mods\bf1942\Settings, and change the setting for this item, renderer.setFullScreen, from 1 to 0 (Tweaktown's Battlefield 1942 Guide).]
Above, we can see what is going on moments after I have spawned on the map for the first time. Notice the frequent frame rate spikes that accompany the choppiness, which I'm sure many are familiar with when they first enter a Desert Combat level. To get some idea of what may be causing this, look at how frequent the disk activity is. Although the number of page faults seems to be dropping off, there's no spare physical memory, and the swap file usage continues to increase. Also note that although the frame rate is spiking, we don't see any corresponding spikes in the other items on the Nvidia Performance Graph, that is, Driver Time or CPU waits for GPU. This seems to indicate that the bottleneck is not in the video card hardware or the video card driver (as processed by the CPU).
Unfortunately, comparing the Nvidia graph (with the yellow, red, and blue lines) to the Windows System Monitors is not straightforward, because they show very different time periods. The Nvidia graph only covers a few seconds of time, while the Windows graphs depict a period that is about 20 times longer (100 seconds). So, in trying to match up the activity that you see on the Nvidia graph to what is shown in the Windows graphs, just look at the data immediately to the left of the vertical red lines.
A couple of minutes into the game, we can see that things have settled down significantly. Although there still are some small frame rate spikes, the average frame rate looks fairly steady. However, there is a constant, though relatively low, level of hard drive activity. It looks like windows is trying to free up a bit more RAM by continuing to move data to the swap file. Although there still are some page faults, they are occurring less frequently.
The above screen shot is after playing for about 7 minutes, and I think that it can be taken as fairly typical for how the game will continue to play. There continue to be occasional frame rate spikes, and these seem to be associated with page faults and disk activity. (We can also see that when I'm in the vicinity of a lot of structures the number of batches increases, and this is associated with an increase in the average frame rate.) Although windows continues to try to free up a bit of RAM by making further use of the windows swap file, there still is not much RAM to spare.
(Although we haven't focused on this, when the game first loaded up it was using about 64MB of video RAM, but as the game has continued, the video memory usage has increased. By the time of the above screenshot, the game is using almost all of my 128 MB of video memory.)
Playing Desert Combat Final with 1GB of RAM
Lets see what happens when using 1 GB of RAM.
The above screenshot is shortly after I've entered the level. While 145 MB of available physical memory doesn't sound like a lot, it is much better than the 41 MB of free memory I had at this point when only using 512 MB of RAM. Most importantly, lets take a look at the swap file usage. I'm only using 1.4% of my swap file (about 22 MB), which is quite a bit less than the nearly 17% (about 264 MB) that I was using at this point in the game with 512 MB of RAM installed. The amount of disk activity seems to be less, as well. While we can still see some spikes on the disk time graph, these turn out to be about the last of them, and disk activity is down to zero at the moment.
Let's skip ahead to see what things look like after I've been playing for about 12 minutes.
Although my available physical memory has come down a bit (by about 10 MB), the most important thing to see is that the amount of swap file usage is virtually unchanged. Although there continue to be page faults, almost all of these seem to be "soft" faults with almost no associated disk activity. Needless to say, this makes for a much smoother game experience than what I had to deal with before.
Conclusion
If your favorites games are running with a lot of annoying chop, before you blame it on your video card or processor and dump a bunch of money into upgrading these components, you probably should look at how much system memory you have. If you are running 512 MB of memory (or less), this may not be enough. The good news is that adding more system memory will likely be less expensive than upgrading your video card or processor. 512 MB of good quality (CL2.5) PC3200 memory costs about $80, and even the high performance stuff can be had for around $140. As a result, this is an upgrade that will yield a lot of bang for the buck, if your system is starved for memory, like mine was.
Happy gaming.
