My system feels sluggish. What's wrong?
This is a question that comes up from time to time. The main symptoms here are slow, not smoothly scrolling of the main map and/or jerkeyness of the mouse arrow when moving the mouse.
While the question is simple, the answer, unfortunately, is not. This problem manifests itself mostly on systems that, while being better than the minimum requirements, don't exceed the minimum requirements by a lot. If it applies to your configuration, it suggests that your system (in it's current configuration) is pushed to it's limits.
- 1 Basic explanation
- 2 Other processes and their effects on Vicky
- 3 Optimizing memory usage in Windows
- 4 What goes on inside the game
- 5 Improving Vicky's graphical performance
- 6 DirectX 8.1 or DirectX 9.0
- 7 What can be done to make turn flow more smoothly
- 8 The impact of in-game music
- 9 What happens if your AGP is not enabled
- 10 Closing remarks
So, why does this happen? Well, for a start this game needs a lot of memory to operate. At least 200 MB of memory gets allocated during a game session. More, if things get crowded with lot's of armies. But, I hear you say, the min. requirements list less than that amount. What gives? Well, Windows has a feature called virtual memory. When the system needs more memory than is physically available, the system overflows into the swap file. Like the name implies, chunks of memory are swapped in and out of physical RAM on a need-to-use basis. This is ultimately controlled by the processor, backed by a piece of kernel software deep inside Windows itself.
What you need to understand here, is that the hard disk (which holds the swap file) is a least one thousand times slower than physical RAM. If the system must swap a lot, then performance of the entire system will suffer greatly, varying from a factor 2 upto at least a factor 50. So, to avoid swapping as much as possible, make sure your system is equiped with at least 256 MB of RAM.
Now, even if you have at least 256 MB of RAM, you can be confronted with excessive swapping. This can be caused by a number of factors. We'll examine the most likely candidates next.
Other processes and their effects on Vicky
There are processes running in the background. While this seems like kicking in a open door, let's not ignore the obvious here. Processes are both applications you have started yourself (like MS Word, Notepad, etc.), but also stuff that gets activated during system start and runs in the background or resides in the system tray. Believe it or not, but this stuff can allocate quite a lot of memory. Furthermore, these processes can use up CPU time even if they are not active. Programs like MSN Messenger do this routinely. This has two negative side effects for our game. First, stuff running actively in the background uses up CPU cycles, which are then not available for our game, making it slower. Secondly, an active process in the background needs it's memory. If this has been swapped out to make room for the memory of our game, then the memory of our game will be swapped out through the activation of such a background process. This means that when our game gets CPU cycles again, it's memory contents must be retrieved from the swap file. This too makes the game slower.
If shutting down processes doesn't give the desired effect, it's time to delve deeper into the system to free up more physical RAM. Luckily, there are a number of ways to improve the memory usage of a default installed Windows system.
Optimizing memory usage in Windows
The hard disk cache
First there is the internal memory usage of Windows itself. Besides the swap file for holding the virtual memory, Windows also allocates a chunk of physical RAM for hard disk caching purposes. The idea behind this feature is twofold. First, it streamlines reading and writing of files. Say, an application reads a file one character at a time. Internally, this will be scaled up to a sector read or write, which is 512 bytes in size. But reading or writing a file one sector at a time is not efficient. It is far more efficient to read an entire track into memory, and this is exactly what the hard disk cache logic does. It reads more data than is actually requested by an application, in the assumption that in a later stage the application will request the other portions of the file too. Then that data will already be in physical RAM, thus speeding up the access to the data in the file. The second feature is that it keeps the result from hard disk read operations in RAM for as long as there is room in the cache. If a program should start reading a file for the second time, the contents are still in RAM, and thus the need to read from the hard disk is no longer there. The data is simply copied from RAM to RAM, which is much, much faster.
Well, this behaviour is counter productive when it comes to our game. The game reads all the data files at the start, and keeps it in memory during the entire game session. This means that by using a hard disk cache, we slightly speed up the initalisation of our game, but slow it down when we actually start playing. The only file access during game play is writing the autosave every once in a while. The rest of the time the hard disk cache sits idly by, but the RAM allocated to it is not available to our game. Luckily, Windows allows for tweaking these memory settings. The easiest way is by using the CacheBooster program from analogx. Simply set a low(er) size for the hard disk cache (something like 5 MB), and reboot. After this, Windows will reserve only the specified amount of RAM for the hard disk cache function, instead of it's default value. Less RAM for the hard disk cache function means more RAM available to applications, which in turn means less overflow into the swap file.
The AGP interface (or aperture)
A second source for RAM loss is the so called AGP aperture size. This is typically something that is set through your system's BIOS setup. Most manuals for motherboards recommend setting this to half the size of your available physical RAM. Unfortunately, this is by far not the best setting for the aperture. To explain this, one must first understand what the aperture actually does. In the early years of AGP, AGP video boards typically had 2, 4 or 8 MB of video RAM. With increasing resolutions and color depth, that meant that a large part of this video RAM was reserved for the actual frame buffer or buffers. Most cards actually have two frame buffers, one that holds the currently visible image, and one that is used to render the next frame. When rendering is complete, the two buffers are swapped, and the process is repeated. This avoids flicker being visible on screen. It also meant that the cards had insufficient memory to do their 3D stuff, and this is where the AGP aperture comes into play.
The aperture holds overflow memory allocations from the video board in main physical RAM, in much the same way as the swap file from Windows holds overflow memory from physical RAM. This memory area is also known as the GART, and the GART driver for your chipset controls it. There is one, very nasty side effect of the GART. As the video card manages the contents of the GART RAM area at it's discretion, Windows cannot use this portion of physical RAM. Consider is permanently allocated for use by the video subsystem (aka card + driver). So, if you have 256 MB of physical RAM, and you have set the aperture in the BIOS to half of that, you actually have created a system for yourself with only 128 MB of usable RAM. Thus, reduce the aperture! Now, I hear you ask, is it wise to deviate from the recommended aperture size? The answer is simple: yes, at least for the purpose of our game. Our game doesn't use (a lot of) textures, and doesn't use 3D, so that memory reservation is a waste of resources. Furthermore, over the past couple of years, the amount of available video RAM has steadily increased. 128 MB is currently the default, and 256 MB cards are appearing as we speak. The cards have so much spare RAM now, that they no longer need the GART memory to overflow into. There is only one restriction here. For some unexplainable reason, Windows doesn't like an aperture size of less than 16 MB, and becomes in fact unstable. So set the aperture to 16 (or 32) MB, and you free up physical RAM for use by our game.
The (negative) impact of integrated graphics
Also, keep in mind that if you use a budget PC (or notebook), these tend to come with so called integrated graphics. While this seems like a nice solution (you don't need a separate video card), this comes at a price. Integrated graphics typically make use of the so called Unified Memory solution. It's a fancy name for using a portion of physical RAM as the video frame buffer. It also means that your system has, in fact, less RAM available to Windows than is listed on the box. If your system came with 256 MB RAM and has an integrated graphics that uses 64 MB, then your actual system RAM will be a mere 192 MB. If possible, try to reduce the amount of RAM reserved for the integrated graphics, This will make more RAM available to Windows.
The sound driver
Another potential source of RAM waste is the sound driver. When the SoundBlaster cards from Creative Labs started to make sound cards popular in the late 1980's, there was only one way to generate music in an acceptable way without completely crippling the CPU's performance, and that was MIDI. With MIDI, an application sends a stream of music commands to the sound cards, and that card uses it's internal synthesizer to produce the actual sinus waves. When compared to actual .wav file playback, it had two distict advantages. First, the then standard ISA bus wasn't completely saturated with a wave file data stream, and secondly it relieved the CPU of shuffling a large amount of data from hard disk to sound card. CPU's back then were still clocked in the tens of MHz, instead of the multiple GHz'es of today's CPU's. Maintaining a wave file sound steam (MP3 didn't exist in those days) would have used up much of the available CPU cycles. For backwards compatibility, most modern sound cards still support MIDI playback, using wave tables. Contrary to the early ISA based sound cards (which had their own on-board memory), these modern cards use main physical RAM to store the wave table contents. And, to that end, the driver reserves a chunk of RAM for that purpose. However, since hardly anyone (especially games) use MIDI anymore, this wave table memory is a waste. Select a smaller soundbank (aka actual wave table contents), and reduce the amount of reserved memory for soundbank usage.
What goes on inside the game
When all of the above has been applied to optimize the system, it still can happen that the game feels sluggish (at times). The game itself contains three major sections, all requiring CPU time. First, there is the user interface, which deals with the commands you issue by clicking somewhere or typing something. Those commands need to be dealt with, and that takeS CPU cycles. Secondly, the image you see on the screen needs to be (re)painted. Rendering the image is done by sending instructions to DirectX, and involve many different drawing commands, most of them deal with bitmaps of varying sizes. Even the little animations you see in the various provinces are nothing more than a sequence of little bitmaps that are displayed consequetively through a timer. The more different bitmaps are overlayed on the main map, the more time it takes to render the entire image in the frame buffer of the video card. Thirdly, there is the actual progress in the game. Each game turn (or couple of turns), a lot of stuff needs to be updated according to the various game rules and formulae. This, naturally, takes up CPU cycles. Things that fall into this categoty are updating stuff in the provinces, in the various nations, (diplomatic) interactions between (AI) nations, firing appropriate events and process the effects, AI decision making, military AI performing it's actions on the various units, actual battle between units, and so on.
When rendering the user interface takes up too much CPU cycles (like: having no animated stuff in provinces lets the mouse move smoothly, having several makes the mouse jerkey), then there is nothing much you can do, except the obvious 3 choices:
- Don't have too much animated improvements at any one time.
- Try a lower resolution for the game. Less pixels to render means less CPU cycles to do it in.
- Install a faster CPU and/or graphics board.
Improving Vicky's graphical performance
If all else fails, there is an additional option available. The main, default terrain map has a fancy looking terrain, which is not visible in the other map modi. Those are simply color coding the various provinces. Well, while the terrain map looks very nice, it unfortunately also places a huge burden on your system. That terrain map is actually produced by painting slices of a very large (as in 120 MB) bitmap on top of the normal map. This has a negative impact on two fronts. First, that terrain bitmap is loaded entirely into memory, increasing the game's memory claim from 200 MB to over 400 MB. If your system doesn't have that much of RAM available, then the swap file performance hit, discussed above, comes into the picture. Secondly, rendering the image takes roughly twice as much time, and thus valuable CPU cycles. Fortunately, there is a way around, by renaming (or deleting) the file tiles.bmp in the map folder of Victoria. When that file is no longer available under it's official name, the game engine doesn't (try to) load it, and the terrain map overlay logic is disabled. That means that in terrain map mode, the provinces are color coded, just like in all the other map modi. It saves precious CPU cycles, and lots of memory.
DirectX 8.1 or DirectX 9.0
If you don't want to see the terrain map disapear, or haven't regained enough performance from removing the tiles.bmp, there is an alternate route you might consider. As you know, Victoria comes with DirectX 9, and if you let the installer do it's job, you will end up with this version of DirectX. However, Victoria run just as well under DirectX 8.1, and, in fact, performs less laggy when used with DirectX 8.1. I found this out recently, when I needed to install a secondary Win98 SE boot for use with DirectX 8.1, as there are some older games (panzer general 3, for example) that fail to start under DirectX 9. Just for the heck of it, I launched Vicky from this secondary boot. It not only started and ran without a glitch, the graphics turned out to be less laggy when compared to my DirectX 9 installation. Just one note though. Don't attempt this if you don't have a good boot manager, as up- and downgrading of DirectX on one single OS is not recommended.
What can be done to make turn flow more smoothly
As for the other noticable delays. There is little one can do about that. That is just the CPU time needed to run the game and it's various AI components. Normally, the game inserts a fixed time between consequetive game turns, in which all of the formulae and AI stuff is evaluated. The amount of fixed time is controlled by the game's speed setting. the higher the setting, the less waiting time between two game turns. Now, this time between turns is not like the 'think' time of a modern chess program, where AI evaluating is cutoff once the time is up. If the game/AI cannot complete it's calculations in the alotted time as set by the game speed, the next turn is simply pushed back, and the interval time between the two turns, as observed by you, the player, is increased to accomodate the AI. Note that any action that is interrupt controlled also cuts into the AI's CPU time (like you issueing orders, or the time spend in DirectX to repaint the image, or a third party process like MSN Messenger running in the background). Lowering the game speed increases the fixed time interval, thus reducing the amount of time the AI exceeds the fixed interval, and thus gives the illusion of a more smoothly time flow. Also keep in mind that during wars individual units are now AI controlled and thus take up CPU time. During peace time, these units simply sit idle and thus cost very little CPU time, if any at all. Same goes for combat. Battle is actually executed as a large sequence of fire engagements between the units, controlled by the random generator. This too takes up CPU time, and lots of it.
The impact of in-game music
Another source of slowdown is the music playback in the game. The music comes in the shape of MP3 compressed sound files. Unless you have a sound card that can decompress the MP3 data stream by itself, it's up to the main CPU to decompress the MP3 file before sending it on to the sound card for playback. This process is rather CPU intensive and needs to be done continuously. Otherwise, the sound playback would be constantly interrupted. This, of course, means that a lot of CPU time gets diverted to music playback, time that is then unavailable for the game itself. So, if the game feels jerkey and slow even after improving the system using the above steps, consider trying to play without the music.
Also, music playback, especially when the CPU does the decompressing, places a burden on your PCI bus. The PCI bus connects all your hardware to the chipset. It runs at 33 MHz, irrespective of how fast your main processor is. The hard disk, CD-ROM drive and other hardware like the ethernet card and sound card (even if you use integrated, AC97 sourd) are all connected to this PCI bus and share the available bandwidth. Any bandwidth used to stream data to the sound card is unavailable to the other devices like the hard disk. This can significantly cripple your system's performance if the game uses the swap file intensively. This will make your game slower.
What happens if your AGP is not enabled
The same applies if you either use a PCI based video board, or you run the video board in PCI mode (thus not in AGP mode). This situation can occur on an AGP based video board if either the driver instructed it to do so, or the (chipset's) AGP driver is not active. When the system runs with AGP enabled, the video board gets a direct and separate channel to the processor and main memory, and thus does not share the bandwidth with the PCI bus and it's connected hardware. When the video board runs in PCI mode, all of a sudden it does share the bandwidth. And this bandwidth is significantly smaller than the AGP interface provides at that. Given the enormous amounts of bitmap data that is needed to generate the image on screen, this will hugely slow down the game. A lot of CPU time now gets wasted on two things: rendering the image on screen and waiting for access to the video board through the PCI bus. If you are not sure how your video board is used, run DxDiag. DxDiag will report if your video is used through PCI or is in AGP mode.
Finally, there may be a problem inside your chipset, causing system freezes, sometimes in excess of 2 seconds. That falls outside of the scope of this FAQ, and is a topic for a hardware FAQ. Those freezes are easily recognizable, as the mouse arrow won't follow your mouse movements, not even in jerkeyness mode.