Convert all textures to .DDS; shrinks mod size by 73%

[StoneBlue]

• Added converted .dds textures
• Deleted all .mbm/.png texxtures
• Modified kOSMachine0mLegacy part.cfg, so its original textures could be deleted, and replaced with the textures for the kOSMachine0m part, using placeholder textures. Only drawback is the legacy part will now look identical to its replacement part.

By converting the textures, the folder size of the mod is decreased from 37.3MB to 8.76MB
Also, some tiny performance gain may be had in KSP, by using the .dds format

[Dunbaratu]

By the way, in the future it's best to make a separate branch for your PR, rather than just using the default name of "StoneBlue/develop". Presumably if you made other changes while this PR was pending they'd have ended up melted together with it. Luckily you hadn't so it's fine in this case.

[Dunbaratu]

I'm not sure it is possible for me to test the Legacy part anymore at this stage. I don't have any savegames from that long ago that would still have had the legacy part in them.

But for that very reason, I'm okay with not testing the legacy part. The only people who will have one in their game are people trying to play a save from over 2 years ago who haven't played since.

[Dunbaratu]

@StoneBlue - would you have any insight into this: As of v1.1.6.1 (which has this PR in it), I got a report that icons that used to work are now coming up black for one user (but not others). I noticed someone (was it you) mentioned widthXheight needing to be powers of 2, but this PR didn't actually do that. It did edit all the PNGs, but many of them still had heights that were not powers of 2.

[Dunbaratu]

@StoneBlue One thing just occurred to me that might have happened here. Your text describing this PR claims you changed ALL textures to DDS, but the actual changes in the PR do not show that. Many of the files are still PNG. Perhaps you did actually generate DDS files for all of them but hadn't done a git add on those new files so they didn't end up in the merge?

[StoneBlue]

@Dunbaratu Terribly sorry.. I have been away from my KSP development computer for a couple weeks, and have only been infrequently checking the forums on a tablet.
I just saw the last few posts in the kOS thread.

Well, I must apologize... I DID say "all" textures... That was not a good choice on my part.
Should have been "all textures EXCEPT GUI textures". I knew of possible issues with using .dds vs .png format for GUI textures. A few years ago, when KSP/Unity introduced the ability to use dds, i had done a bunch of research and Googling on it.
There seemed to be a lot of mixed info and i could never find a definitive answer. The majority of it seemed to lean toward not using .dds, but leaving GUI textures as .png, or possibly .tga...

So while I did slightly resize quite a few of the GUI textures to fit the power of two rule, mainly to cut down on log spam, I did leave them all as .png on purpose, so as not to introduce any unforeseen issues with a full format change, due to my lack of specific knowledge with GUI textures.
Thats why my original Dec 18th PR had no changes to the GFX folder...
Then when troubleshooting issues for another mod, I noticed all the log spam for the kOS GUI textures...
Thats when I resized them, and added the Jan 9th changes.

You just need to go back to using the .pngs in the GFX folder in the PR.
I profusely apologize for not making specific note of NOT converting those GUI textures to .DDS.
Thats all on me.

[Dunbaratu]

@StoneBlue

You just need to go back to using the .pngs in the GFX folder in the PR.

Are you operating under the impression that this was the order of events?

1 - I merged your PR. With the icons resized but still PNG.
2 - I changed your textures to DDS. It worked in my testing.
3 - I made the v1.1.6.0 release with the DDS icons I made.
4 - Some people reported that v1.1.6.0 broke the icons turning them into black squares on their computers in the v1.1.6.0 release. With the DDS icons I made.
5 - I made another release trying to fix it.
6 - Most people reported it's fixed, but one new person has a new problem with the texture being purple (not black).

Because that isn't what happened. At all.

It was in this order:

1 - I merged your PR. With the icons resized but still PNG. It worked in my testing.
2 - I made the v1.1.6.0 release. With the icons resized but still PNG.
3 - Some people reported that v1.1.6.0 broke the icons turning them into black squares on their computers in the v1.1.6.0 release. With the icons resized but still PNG.
4 - NOW is when I changed the icons to DDS) - AFTER getting complaints using the resized PNG files not working - AFTER the relese of v1.1.6.0 with PNG files in it.
5 - I made another release trying to fix it.
6 - Most people reported it's fixed, but one new person has a new problem with the texture being purple (not black).

The PNGs in the original PR started the problem.
Also you described their dimensions as being changed into powers of 2. This is NOT what I found in the PR. (Take the example: terminal-icon-open.png the PR turned it into a 28 pixel high PNG image when it had previously been a 27 pixel high PNG image. Neither of these two sizes is a power of 2.)

[Dunbaratu]

I have an idea about what might have happened here. But the issue is so convoluted I don't know if I have it right.

For one thing I saw other reports on this issue (I had to go do a lot of reading too after this) claiming that powers of 2 aren't what you need to convert to DDS, just multiples of 4 (thus the change from 27 pixels to 28 would be significant, while if it was keyed on powers of 2 it would not).

So in testing the mess I also found another fact that's important: KSP attempts to convert all mod's PNG textures into DXT5 compression upon loading them into GameDatabase.Instance. So even when we ship PNG files, it will try to make them into DXT5 compressed format when loading them if it can.

And I think that's where the file size changes triggered something. By making the PNGs into a multiple of 4 (28 pixels high when it was 27, for example), you made it possible for KSP to attempt this conversion when before it gave up because the size didn't match.

Therefore if you want to ensure that the GUI textures remain as PNG, you have to make them not compressable, which means NOT a nice multiuple of 4. Exactly the opposite of the advice everyone keeps giving. They won't stay as PNG unless we can befuddle KSP's attempt to convert them automatically by deliberately NOT making them a convertable size.

It may turn out that those errors you saw about the failure to convert were actually a GOOD thing and we didn't know it. Because the conversion doesn't seem to work right on some installations, and I suspect it's because when KSP does it at runtime it ends up using the graphics card to do it, and that's what makes the results driver-dependant.

By converting to DDS w/DXT5 myself I bypassed the (apparently quite buggy) step where the game tries to do it at runtime.

There is another potential fix. We can just bypass KSP's GameData.Instance loader entirely here and just obtain the textures ourselves instead, and entirely bypass the game's attempt to compress to DXT5 (which is what causes the bugs it seems). That seemed to have worked in the past. We used to do this for a few of the files and I just got done changing all that code over to using GameDatabase.Instance.GetTexture() instead as part of the DDS change in v1.1.6.2.

Maybe the fix, instead of moving everything into GameDatabase.Instance.GetTexture(), is to move everything out of it, so it stops trying to invoke its broken conversion into DXT5. We can call the Unity texture loading directly and explicitly tell it that it's okay to leave the files uncompressed. The Terminal code used to do it that way before v1.1.6.2 where I made everything DDS and also moved everything to GameDatabase.Instance. I could make the ToolbarWindow code do the same thing and have it stop using GameDatabase.Instance too.