I highly suspect this is something that Squad is going to have to implement. It is going to require tight integration with how resources are loaded, which I kind of doubt we can mod effectively. If you will recall from Harv's rant on the subject , the amount of work to improve a feature begins to increase the more complete the feature is. In this particular case, in order to to go from "we can load parts now!" to "we can load parts faster!" is probably significantly more work than it required to load parts in the first place. A significant amount of time that the developers could be using to work on things that don't work at all (like career mode, apparently). There are significant reasons why any major game now-a-days caches game resources, or uses a single really big file to store everything (or both). Reasons that will eventually compel Squad to do the same. Now, for the not so faint of heart, I am going to address some technical aspects, sort of in reply to these. While reducing the amount of memory used is nice, it isn't really the point. I am going to introduce a Golden Rule: It takes longer to find something to do than to do it. That is, the amount of time it takes to get the appropriate data to the appropriate chip is a significant part of the time it takes for that chip to do the things you want it to. Little details like the cache miss penalty don't phase algorithm guys, it is O(1), dang it! (For sufficiently large values of 1.) The great thing about these particular compression algorithms is that they are supported in hardware by virtually any video device worth talking about made in the last decade. Because they (usually) operate on a fixed 4:1 compression ratio, and the video card supports the format, when you transfer textures from main memory to video memory along the relatively slow bus in between, you only need to send 1/4 of the data as you would for an uncompressed image. This means that the video card can spend more time doing the things you want it to, and less time waiting for you to tell it what things you want it to do. This is a good thing. But it gets better. The video card actual stores the textures compressed in video memory. Because video memory is generally pretty limited, this means that you can fit more textures and whatnot into video memory. In addition, if you have more stuff to draw than you have video memory available--which is generally the case--you have to resend textures that the video card dropped because it didn't have room for them "occasionally." But you are resending 1/4 of the data... less often. Fantastic. But wait, there is more. The GPU can actually operate on these compressed images more or less in situ; that is, basically any operation that it can perform on a texture, it can perform directly on a compressed texture, in hardware, without having to decompress the image first. And because the compressed texture is 1/4 the size of a uncompressed texture, these operations require 1/4 of the operands to get loaded into registers across the relatively slow bus between the video memory and the GPU. The GPU can probably work on them as fast or faster than an uncompressed texture. Is this sounding too good to be true? It is. There are a number of limitations. The first (and only one that is really relevant) is that they are patent encumbered. A portion of the cost of your video card goes to pay for the license fee that the manufacturer must have to support these algorithms. A portion of the price of Windows goes to pay the license fee that Microsoft must pay to support them in DirectX. This is all well and good, unless you want your program to run reliably on non-Windows platforms. (Especially the ones where people don't like to pay license fees.) There are alternatives that, AFAIK, carry more or less all of the same benefits at a slight image quality penalty without being patented. The upshot of this is that a contentious developer cannot distribute the textures pre-compressed. They need to ascertain the best supported format on a particular system, and cache the compressed results to be subsequently reloaded as needed. This caching business has pretty significant benefits in addition to avoiding re-compression on every load. The method in which all the data is currently stored is... suboptimal from a performance perspective. And it goes back to our Golden Rule. When reading a whole bunch of relatively small files, the cost of FINDING those files is a significant portion of the cost of READING them. Let us suppose that I want to read the file "C:\Users\me\Desktop\KSP_win\GameData\Squad\Parts\Aero\CanardController\model000.mbm". Let us further suppose that the guy at Microsoft that wrote the filesystem was a little naive... mostly so we don't have to go over all of the provisos. (Generally, if you used it recently, it is probably cached; if it was adjacent on disk with something you recently read, it is probably cached.) Finding a file (naively) goes something like: 1. Read the Master File Table (MFT) to find the entry for the root directory of "C:" 2. Open the file $Secure, read the list of Access Control Lists (ACLs) to find the ACL that controls access to this directory. 3. Determine if the current user has the appropriate permissions. (This probably involves reading stuff from somewhere... you know, enumerating group membership and whatnot, but I wouldn't know where offhand.) 4. If so, use the disk address provided in the MFT entry for the directory to find the listing of the contents of the directory and search it for the entry for "Users" 5. Using the information we just obtained, find the entry in the MFT for the directory "Users" 6. Open the file $Secure, blah blah blah, the current user has permission to open the directory 7. Use the address provided in the MFT to find the listing on disk, read it, and find the directory "me" ... N. Using the information we just obtained, find the entry in the MFT for the file model000.mbm N+1. Ascertain if the current user has the appropriate privilages. N+2. Read the file. N+3. Oh yeah, by the way, update the Last Accessed Time for all of the files and directories we just touched. (Wait, we have to write to disk even though we just wanted to read? Whose bright idea was THAT?) (This operation is actually deferred for potentially an hour, but I mention it because we are increasing the disk load when we would rather our computer was focusing on playing KSP.) From the naive approach, you can see just what a travesty trying to find a small file could be. Even if you factor in all of the provisos it is still a significant penalty. But wait, it gets worse. When you defrag your hard drive, like everyone tells you you should, it is just making sure that individual files are in one contiguous piece. It doesn't do anything about related files. Even though model000.mbm and model001.mbm are in the same directory, there is a pretty stiff chance they are nowhere near each other on disk. This is important because, for those of you that are still tortured by spinning platters instead of a solid state drive, the time it takes to move the read head around (and for the disk to rotate to the correct orientation) are pretty significant--overwhelming even--to the cost of reading a few sectors. (There is our Golden Rule again.) For good performance, you want all your data in one nice continuous piece so you never have to move the read head around. These two reason are why most fully-developed games (which KSP is by no means) go for a humongous file with everything in it instead of a humongous pile of little files. Now, I highly doubt Squad is going to move away from the humongous pile of little files because that is how to mod the game and whatnot. But by doing any necessary pre-processing and then storing all/most/some of the results in a cache file of some sort they could potentially realize some pretty significant savings on the load times. They could even, if they did it right, start to drop resources from memory that are not being used at the moment (because it is now (hopefully way) cheaper to load them from disk again when they are needed) so they don't smack their face against the 32bit address limit as much... but that is getting a little more off topic. The trick is that doing it right is not really a walk in the park and, because of the mods and whatnot, detecting cache invalidation reliably is a pretty important to get right. The naive ways of detecting cache invalidation--"just MD5 the file!" doesn't really help you any, and I don't trust file timestamps for some reason--may or may not be robust. In order to get it Right , this is something Squad is going to have to implement. You might be able to Fudge It , though. My spur of the moment idea is make a mod which: After all the resources have been loaded, for each part: - if the part has a placeholder texture, load the real pre-compressed texture(s) for that part from the cache to replace the placeholder - otherwise, store the compressed real texture(s) in the cache and replace (with a backup of course) the texture file with a placeholder The chances of realizing any appreciable savings with this method, however, don't seem compelling enough to outweigh the effort it would take (for me) to try it to see. If someone has this modding thing in the bag and has nothing better to do, go for it! So the bottom line is that texture compression is a good thing, and I can't wait for Squad to run out of other things on the TODO list. Mostly because the other things on the TODO list are probably pretty cool, and then I wouldn't have to wait as long to get to play with those cool things. The status quo does give me an excuse to go make a sandwich before I start crashing things, though... I am actually kind of scared at how long this post probably is. **Averts eyes from screen in horror while click "Submit" button**
