Lilleman

I noticed a few bugs with arguments, and some of them are not acknowledged. Flags and agencies logos are rescaled as well... I'm rewriting that part, and cleaning the code a bit in the process. I'll release it asap, probably tomorrow. For now, better not use the resizing option, sorry.

OK, I thought you were talking about window style (I'm keeping the "Windows 95" all-grey theme, so I don't really pay attention to aestethic). I'll look into this. (By the way, it seems like Ooki is compatible with .NET only, anyone knows of a similar, cross-platforms GUI library? I'm considering re-writing the whole thing with Mono and SharpDX, so Linux and Mac users could use it as well)

I forgot to uncheck the "Use windows XP Visual style" checkbox before compiling this:blush:... I'll do it for the next release (I noticed some bugs in the arguments detection process that needs to be fixed, I'll try to do it for tomorrow). Edit: It's VB.NET, so once compiled it's the same executable as it would have been with C#.

@Slumpie: Yep, it's only a problem for shrinking textures, if you let the Resize ratio to 1, this won't be a problem. I suppose the game reduce the resolution to reduce charge on the GPU, but it still has to load the texture with full size before that, so it's not the best for RAM usage. @John FX: It should delete files automatically if it successfully convert them to dds. Unsupported formats are left untouched. You don't have to delete anything after a batch. But the memory issue is weird, it shoudln't happen. Does this install worked without conversion?

@Telanor: I've made some tests with the lastest version of KER, and it should be OK. The compression algorithm is quite agressive with icons and small textures in general, so as a workaround, they are now saved in an uncompressed format. ModsExceptions.txt also got a new line for KerbalEngineer, otherwise the toolbar icon is detected as a normal. I'm wondering if I should convert A8, L8, A8L8, L16 and stuff like this into dds: those compression methods are more effective than dxt's. I'm not sure there will be any benefits for these particular formats. Still, for now the program can't convert them at all, and it's a problem for the rescaling options. I think I can save them in their original format, even rescaled. Problem with this is: the program don't keeps tracks of what's been converted, it only ignore files that are not tgas, pngs or mbms. So if a rescaling batch is launched several times, those textures will be rescaled every time... It could have a file to store this files list somewhere in the GameData folder (or directly in the program folder), but it's not really an elegant solution...

I wanted to wait a while to release the source, since it's probably one of the messiest code I've made and I'm still cleaning it (I've just some bugs with the way it handles arguments, I'm rewriting that whole module, lots of old debugging function are still here, etc...)... Please don't judge me... Link updated. Licence is GNU GPL, I guess ("do what you want with, don't take me for responsible if it fails you", or something like that).

Quick fix available! (For my converter, not for DDSLoader, of course). New, amazing features: -If it fails to load a texture, it will just skip the conversion and put a new entry in the log, instead of crashing. I'm still looking for a way to convert them (all 16Bpp images fail to load). -If the resolution is lower than 64(width or height), it will always save the file in an uncompressed format. This should avoid blurry icons. ...And that's it for today... I also updated the modsExceptions file, to include some new mods I've tested: KerbalAlarmClock is not working, but I think it's looking for pngs, directly from the code.(Anyone can confirm if this is the case, or should I look into file formats?) B9 can now be processed in a single batch (instead of crashing, yay!), but lots of textures are skipped... No luck with RealSolarSystem... Though, I got most parts pack converted without errors (KAS, KWRocketry, Novapunch, InfernalsRobotics, TACLifeSupport, Karbonite, and some more). Again, you can PM me directly your error reports and logs if you encounter any problem.

For a folder conversion, the checkbox for deleting files after conversion should be checked by default. But about memory usage, you will see better resuts if you do the other way around: keep mbm and convert TGAs/PNGs (for a vanilla install, there shouldn't be any problem for converting everything). And about icons quality: when the program encounter a texture with a resolution (width or height) not equal to a multiple of 4, it try to resize it and transform it into a blurry mess (from the coder POV: I can't seems to choose the compression method for DXT, only filters, so I've got to experiment with other libraries and it might take a while)... I'll see if I can implement a workaround, but for now I recommend setting the "minimal size for conversion" to 48*48, so it won't try to convert most of icons and let them to their original formats. I've made a quick fix, so it should not crash when it encounter a unknown format and put a error in the log instead. Got some tests to do, but I'll release it later today.

@Crater: I'll download these mods and take a look at it asap. I'll update the link then. Thanks for the report. You can PM them directly to me, as they're not related to DDSLoader. I should probably open new thread, I'll see after some feedbacks. I'll try to fix the A8L8 issue. I know the program has trouble with P8 image format too, you might want to be aware of that (edit: and, after a quick test, also L16...in fact, anything different from 24Bpp or 32Bpp). The fuelTankX200-16 conversion should be working.... I'll look into this too...

You can extract the archive anywhere, then run the program. You can open a single file, or a whole folder (usually, a mod folder or directly the GameData folder if you like to live dangerously). It should detect automatically the best format for conversion, but it will not convert anything by magic: the program can still fail to detect the correct format (or to save in a correct format), and in this case some arguments can be setted in a external file. I already put some exceptions for kOS, Toolbar, EVE, and to avoid resizing of flags and agencies logos. (edit: also, reflections textures used by textureReplacer are skipped, because it still can't convert them properly). It generate a log.txt file to keep track of things, so you can check what happened to your files.

Here's one for windows. I don't release the source yet, because it's a uncommented mess and I'm still working on it, if you want to take a look at them just PM me. If it crash at opening, you'll probably need to download some DX components. I've planned to switch to another library to avoid this, but some DX9 games required this to be installed, so maybe you already have it installed on your computer. Please PM me directly for any feedbacks/suggestions/problems.

@tater: I'm experiencing the same problem with a stock install, it's not related to any mod. I've already seen this somewhere else, but I can't find anything related in the "support" section of he forum. I didn't find a confirmed pattern to reproduce it, but generally it happens after a reentry, or after changing SOI. Going back to space center/switch to vessel seems to fix this most of the time (quite random bug, I've experienced it several time without being able to determine what's causing it). I don't use ATM, so I can confirm it's not caused by this mod.

I'm still working on the user-friendly version for windows, but I've just realized it might ask for DirectX runtimes. So long for the "stand-alone" idea, the full download for this thing is 100MB... As it's something that might be required for some games, hopefully some people already have it, but now I'm trying to work around that. I'm actually considering rewriting it to use SharpDX, originals DX libraries have been a pain to work with since the beginning... It might have been a little optimistic to say "before the end of the week", but I'll see what I can do today.

I just tried the 1.4 build, (until now I was still experimenting with 1.1) and it seems like some textures needs to not be loaded as "read-only". For instance, while TextureReplacer's reflections textures can be converted and used with 1.1, since 1.2, I've got this kind of errors spamming all over my logs: "[TR.TextureReplacer] UnityEngine.UnityException: Texture 'TextureReplacer/EnvMap/PositiveX' is not readable, the texture memory can not be accessed from scripts. You can make the texture readable in the Texture Import Settings. at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixels (int,int,int,int,int)" Full logs are here if needed, from an unmodded (well, apart from this mod and TextureReplacer, of course) x86 KSP. ...Or did I missed something again, like setting a flag or such? (It wouldn't be so surprising, as I said I kind of run straight into every possible obstacle)...

For now, it only ignore 1*1pixel images, but I can add an option for a minimal resolution. Since I got most icons working properly, I don't think this will be necessary, though. By default, the program check a text file listing every exception, it can be a single file or a whole folder. For now, it only has 1 line to exclude some kOS textures. The rest seems to be working, but I'm not done testing, so I'm sure this list will grow. As for block compression, nothing is rescaled, but I didn't encountered problems yet. Any mod in particular where this is a problem? I would like to see if this works. I didn't tried uncompressed formats yet, I'll test those and see how that works. I'm wondering if adding an option to reduce texture resolutions would be a good idea... It's kind of stealing ATM's work... Edit: I feel like I'm polluting Sarbian's thread with all this, maybe this should go to another thread while it's not ready to be released.

So, just to be sure I can keep the code I already made for modifying byte#35: This time, byte#76=0x80, right? I hope it is, in this case I'll just have to modify one line. Anyway, I've almost finished my converter, just have some cleaning to do in the source. I swear this is the last time I deal with DirectX directly, next time I'll go with an external library: I finished squeezing memory leaks at 3AM, and it still sometimes randomly crash when it load a tga or a png (that sounds familiar). For now it's very basic: it can load a mbm, tga or png and convert it automatically into a dds, and it can do the same with a whole folder (with a list of folder/files to exclude if needed). Since I plan to release it eventually (hopefully before the end of the week), anyone think of a function I could implement while I'm at it? I don't know if running straight into every possible obstacle could be considered as "good work", but, yeah, I guess someone had to do it...

It should be the same as any other game, just be sure the nVidia's control panel get the right executable: If you're using x64 for instance, you'll need to add a new profile manually: control panel->"Manage 3d settings", then in "Program Settings", click on "Add" and browse for your KSP's executable (KSP.exe or KSP_x64.exe)

My bad, I missed an argument when loading my normals trough D3D's TextureLoader... Apparently if you don't apply a filter to mipmaps manually, DX decide to convert those into a blurry mess... But only for normals, regular textures mipmaps looks fine... I still got some tests to do to see wich one provide the best quality, but at least I know where the problem come from. Sorry for wasting everyone's time again...

Thanks for the clarification, I was thinking mbm files were handled the same way as any other file, and it was driving me nuts. The RGRA thing was something I came up with after trying to reproduce nvdxt's dxt5nm files. I guess I can cut that swizzling part out of my code now. I've spent way too much time trying to figure this out... I would like to apologize to everyone who tried to help me, somehow I tried to make things more complicated than they really were... For the rest, I ended up with a (kind of) similar logic for conversion (sort of, I actually convert non-mbm normals to (0x80)G(0x80)R instead of GGGR, but that's not really important in this case), so fortunately I won't have to re-write anything in my code. The next tricky part will be to determine if a TGA/PNG file is a normal (I hope checking filenames and blue channel will be enough, because it's my only idea for now). @shaw: Are you sure normals should have mipmaps? I made one test, converting the av-r8 winglet normal with mipmaps and I got weird results when zooming out.

Well, as I said, I don't really understand why it works. It shouldn't. I tried different swizzling from a raw image (mbm files are 20bytes header + raw data) without being able to get the "correct" format to work. Here is the dds my prog produce (using RGBA->RGRA logic), and this is what it looks like in-game... If someone has any explanation to this, please let me know, I'm trying to code a tool to automatize the process, and, even I got it working somehow, I want it to be working properly... Edit: this is still for the Rockomax x200-16. Edit2: This dds probably contains mipmaps, so you might get some weird results if you're zooming too far, that's just because I didn't implement the option yet (it's planned). Edit3 : Sarbian, Github is up to date, but the link for the build in front page still point to 1.1.

Well, I was focusing on mbm files. And they seems to have their own rules regarding swizzling... I just ran some tests with TGAs, and this time Unity expect xGxR format. So you were all right about that, RGRA isn't a format Unity should use (I really don't get why this is working.) As a result, my code is a mess (programming in VB don't help), since it now has two separate functions for swizzling, and it has to perform a bunch of tests to get the right conversion parameters... I'm starting to understand why my first batch with Crunch did not convert half of my textures properly...

Yep, I was talking about mbm files, but I ended not using the nvdxt5 command. I've made a small program to do the conversion automatically, that use the DirectX API. Since it doesn't have native dxt5nm support, I have to do the swizzling "by hand" before saving the file to dds. RGBA->RGRA was the result of trial and errors, and even if it does not make any sense (as stated earlier, Unity shouldn't be able to use those), they are exactly the same as nvdxt's files... I don't really get it, but as long as it works, I don't really bother. MBMs seems to be an exception, though, I think I'll have to use gggr for some other files (the AV-R8 winglet normal, for instance). It's easy to determine when a mbm is a normal, it has a flag in his header. For TGAs files, however, either I look in the file name for something familiar ("nrm", "normal", "nm"...), or I check if all pixels have their blue channel set to 1 (0xff). Probably not the most efficient solution, and it could be a problem for some textures... Though, I didn't encountered "pure blue" textures in KSP yet, so this will probably do the trick...

I've done some "reverse-engineering" (okay, maybe it was bruteforce) in order to get my files converted exactly the same way as nvdxt's dxt5nm. For now I got it working with RGBA->RGRA, but I've only tested a few files. It surprised me too, since I didn't see this format elsewhere yet... But it looks like it works.

OK then, I'll go with modifying byte #35 for now. Then I'll have to compile a test fork of your dll to check how this works. Of course if you plan to implement another way to determine if a dds is a normalmap, I'll adapt my code. I would actually prefer this solution over an external text file, but both have pros and cons.

@shaw and rbray89: Thanks, I finally figured it out: swizzling from RGBA to RGRA, then compress to dxt5 seems to do the trick. (It was working just fine using nvdxt, but I'm trying to get rid of external programs) @Sarbian: I was thinking of changing the first 4 bytes of the dds header from "DDS " to something like "DDSn", since your code already has some functions to check this easily. Don't know if this could be a problem for Unity, though (does it check file headers before loading?).