• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

jpd

Entil'Zha Anla'Shok
Moderator
42 Badges
Apr 19, 2001
8.215
1.806
  • Stellaris: Apocalypse
  • Hearts of Iron 4: Arms Against Tyranny
  • Hearts of Iron IV: No Step Back
  • Hearts of Iron IV: By Blood Alone
  • Battle for Bosporus
  • Stellaris: Ancient Relics
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Distant Stars
  • Stellaris - Path to Destruction bundle
  • Hearts of Iron II: Beta
  • Europa Universalis IV
  • Arsenal of Democracy
  • Hearts of Iron IV: Field Marshal
  • Hearts of Iron IV: Colonel
  • Hearts of Iron IV: Cadet
  • Hearts of Iron IV: Death or Dishonor
  • Hearts of Iron IV: Expansion Pass
  • Hearts of Iron IV: La Resistance
"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.

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.

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.

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 applocation 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.

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 www.analogx.com 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.

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.

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.

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.

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:
1) Don't have too much animated improvements at any one time.
2) Try a lower resolution for the game. Less pixels to render means less CPU cycles to do it in.
3) Install a faster CPU and/or graphics board.

In some games, 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.

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.

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.

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.

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.

Jan Peter

Last edited to include the MP3 music section and PCI video section.
Last edited to include comments regarding DirectX 8.1 and 9.0
 
Last edited:
I will just sticky this, thanks for your insight as always jpd!

I would also add that a virus scan and a look at start-run-then type "msconfig" and look under the start tab. You maybe supprised at how many things are being loaded automatically in the background. Also look at the startup folder in the start menu to see what is in there. It is possible to run a very clean system, myself the only thing that loads at start up is some MS office stuff, there is nothing in my system tray(the area in the bottom right coner of the screen where the clock is).
 
Some users have reported that reverting to some older video drivers helped speed up the game considerably.
 
Summary of the changes to make in Victoria/map and to the colorscales.csv to improve game loading speed, originally posted by Darkrenown

Darkrenown said:
This is something Pimparel discovered:
in ...\Victoria\Maps, there is a file named tiles.bmp; rename it to
tiles.bmp.bak.

in the same directory in the file colorscales.csv make this
modification in the dark orange subsection

dark orange;;;
red;green;blue;index
210;250;160;0
180;220;130;25
150;190;100;35
45;80;20;64

now load the game and experience a way faster Victoria...

To make this easier, here's an already changed colorscales.csv, just overwrite your old one and rename tiles.

It makes the terrain map look rather like EUII, but the game runs MUCH better.

http://www.europa-universalis.com/forum/showthread.php?t=151166&highlight=orange+faster

reposting this as I had to spend 20 minutes searching old threads to find it.
 
Good post, but would love to have an update on it.

You gave a very detailed post, but my computers blow away the requirements (2GB RAM and 1GB on the other, Raptor Drives, 7800 GT SLI and ATI 1600 on the other, Gigabit network, the hole nine yards). All this and I still get the slow down you mention. Admittedly I mostly play MP, but I ususally get the effects within an hour of playing. It causes ghosting and makes some commands unresponsive causing us to restart the game. Any updates on this?

Thanks,
Paul

I own EU2 HOI HOI2 HOI2DD VIC VICR and quite a few of your third party games. Keep em coming!
 
pdfitzg said:
You gave a very detailed post, but my computers blow away the requirements (2GB RAM and 1GB on the other, Raptor Drives, 7800 GT SLI and ATI 1600 on the other, Gigabit network, the hole nine yards). All this and I still get the slow down you mention. Admittedly I mostly play MP, but I ususally get the effects within an hour of playing. It causes ghosting and makes some commands unresponsive causing us to restart the game. Any updates on this?

Thanks,
Paul

I own EU2 HOI HOI2 HOI2DD VIC VICR and quite a few of your third party games. Keep em coming!

I've experienced the exact same thing. It only occurs in MP-games for me (not for my partner). Everything is extremly sluggish with one exception - if I turn on the infrastructure mapmode. No units are shown on the map in that mapmode.
 
My system is also in excess of the minimum requirements, and I am suffering from chronic slowdown in SP mode.

Game version: 1.04 (Revolutions)
CPU: AMD FX-55
RAM: 2Gb
GFX: Geforce 6800GT

Latest drivers for everything. I always use "Political" map mode, so the background graphics aren't a problem. Changing the units to "icons" didn't help either.

Is there a way of increasing the quantity of RAM assigned to the game?

Edit: I've just discovered that it is one particular game that is giving trouble, and that the save file for that game is 149Mb (loading another game or starting a new game gives no trouble). What on earth happened to bloat the save file so much?
 
Last edited:
AoE said:
Would someone please tell me how to remove the Video at the start?

Thanks.


Delete your "avi" folder in your Victoria main directory (folder).
 
In terms of performance, I find that the game runs very slowly if I use my laptop with the battery. However, with the battery removed and running on just AC power, the game runs great just like my old desktop. Just thought I'd throw it out there for our gamers-on-the-go. :)
 
Multiplayer Sluggishness

I also have far exceeded the requirements for the game (I7-920, p6t deluxe asus motherboard, radeon sapphire 4850 HD, 3gb ddr3 ram ... running XP), and as the others have mentioned, it does start being sluggish after a while on multiplayer. I think we can rule out the computer portion of the
requirements, so that leaves what? The internet connection.

If your internet connection was too slow it would be happening as soon as you launched the game, and the host would not see the lag. Saving and reloading the game also would not help.

The issue is not with connection, but stabillity. Every time you save and reload after being laggy for a while, you may notice some things such as ... you have more or less money than you did before reloading... you weren't able to use pops that had been split in the laggy game, even though the + button was not grayed out, but they are in factories after the load ... the issue is synchronization, and it happens to me in all paradox games. In SR2020, i may be fighting a war with imaginary troops, because the troops i am ordering around have already gone to redeploy in reality. In Hearts of Iron II, the clock gets behind sometimes and I have to pause to catch up. Some times even pausing doesnt catch me up entirely and so I am losing time on every action I would have made. This has resulted in my asking "what date do you have" to my friends every time we have to pause to catch up.

A remake will change things for you because the host is usually the one that saves, and you use what they see. This matters most to me in SR because I may have just taken over poland and austria only to discover I dont actually have all of their country, and all my troops have been repairing. If you save, instead of the other person, they can use your save, however SR saving works differently than the other paradox games. Instead of transferring your save before starting a game, when you save your game, it tells your opponent to save aswell, and labels them as the same thing. This does not help synchronization and often will crash if you try to load. The same goes for if the host tries to save. A way around this is to make your save, close the game, get on an instant messenger and (compress if your computer can do it quickly enough or your upload speed is a bit slower, to make it worth the time) send the save to your friend, replace the old one and you're good to go, until you go out of synch again ... you get pretty fast at doing it after playing a couple games through to the end.

Although that helps with a lot of problems, some times the saves are corrupted and I dont know what causes this or how to fix it. Loading the save results in a crash and you have to roll back (before the event that corrupted it, which is tough if you dont know how far that is), or restart.

Now i'm only a gamer, not an internet technician, but these are some of the things i've been able to figure out simply by looking at what happens when, and by communicating with my friends. Also, my problems may be more severe than others because my internet is prone to desynchronization regardless of the game or program I'm running on the internet, though others posting about the problem shows me that it's not just me. I hope this helps some of you, thanks for taking the time to read.