One of the biggest problems modders and their fans run into is the issue of memory management. When you’re a game developer creating content for consoles or mobile devices, you have a specific memory budget that you have to maintain. This requires hard choices during development, and one of the first places to cut is on texture resolution. Every artist wants to make their work look as good as possible, so telling someone to smash their gorgeous 2048×2048 texture down to 512 (or lower) can be met with resistance.

In modding games like KSP, which don’t (yet) have a stable 64-bit build for handling a large number of graphically-heavy additions, you end up killing performance or outright crashing the game (usually the case, with KSP). KSP crashes hard when you hit a magic wall of memory utilization. (Usually around 3,500,000 of private memory for the app.)

There’s a few factors in play. Initially, developers were using TGAs, as they are generally the basis for most game art. They give you good quality, transparency channels, and are readable by any decent app under the sun. Unfortunately, they also gobble memory like there’s no tomorrow. If you don’t have a technical director overseeing a project, you suddenly get a mod full of super-high-res beautiful textures (or a huge mod with lots of smaller high-quality textures) but you can only use so many of those before crashing.

Another thing modders need to watch out for (who don’t have experience with game-specific art) non-square textures can take up as much texture memory as a square texture the size of the longest side of the image, because of the way game engines and graphics cards may process textures. This is not a 100% rule, see these threads (polycount.com) for more info and tips.

Truth be told, cutting resolution isn’t usually a huge sacrifice. Texture compression (such as DXT) and good resampling can give you excellent quality without significant sacrifice in visual fidelity.

Unfortunately, even with good discipline by mod teams in creating tight, well-optimized textures, the KSP mod community has a huge number of excellent mods, and the math just ends up getting you to the same place. (Crashville)

KSP modders have come up with a few fixes for this problem.

• Load batches of different mods, depending on what part of the game you’re playing.
• Active Texture Management: A great mod by rbray89, which will read the game’s (and other mods’) textures, and compress them and store them in a texture cache for better memory utilization. The utility is also configurable for quality or increased compression values.
• DDS loader: TGAs, PNGs, etc., are not a format native to graphics card processing. They need to be interpreted for drawing on your screen. DDS format is one that is more of a native format for your GPU to process, and allows improved loading time because of the lack of processing. To take advantage of this, Sarbian released DDS loader, which allows KSP to make use of the optimized format.
  • For Windows, KSP to DDS will allow you to batch convert the base game’s textures, as well as mods’ into DDS for the plugin to use.
  • For Python fans, here’s another version, img2dds

As an example, here’s the results I got in my testing:

	Commit	Private
OpenGL+ATM	2,159,000	2,068,000
OpenGL+ATM+DDS	1,936,000	1,875,000
DX11+ATM+DDS	3,762,000	3,303,000
DX11+DDS+Full Res	Crash
DX11+DDS+ .5 Res	2,978,000	2,800,000

* Command line parameters for DirectX 11 and OpenGL:
-force-d3d11-no-singlethreaded
-force-opengl

UPDATE (2014/11/24): I haven’t done comprehensive testing using FRAPS, but it appears to the eye that enabling threaded optimization for OpenGL in the NVIDIA control panel will improve your framerate consistency.

Because I get a higher framerate in DX11, and the source textures are all high quality, I went with the last option. Not as low on utilization as OpenGL, but noticeable performance improvement across the board, as well as better display of normal maps on my hardware. (GeForce 7-series).

UPDATE (2015-06-10): It has come to my attention that something appears to have changed with the DX11 command line option. Previously, I saw no difference using -force-d3d11 vs. using the “no-singlethreaded” option listed above. Now, I find that -force-d3d11 allows me to run the game when only OpenGL would allow me enough memory to do so previously. I am currently using both ATM and D3D11 on KSP 1.0.2, however as more mods transition to DDS format textures, the need for ATM goes away.

Thoughts? Comment below.

See my list of 0.25-compatible mods I’ve tested and use.