rbray89

I suspect we should be fine. I once wrote a multi-producer, muti-consumer queue (every element had to be processed by all consumers) where everything existed on their own threads... THAT was fun

Haha, that is what I worry about Thinking about it, the libsquish implementation would be more likely able to be multi-threaded, but the Nvidia one uses static objects. Probably why the NVidia implementation seems faster as it is(less dynamic allocation & garbage collection). I'll give it a shot, and see where we get.

That's the thing though, I use the Unity operations pretty much everywhere. And we all know unity wasn't designed around multithreaded operations.

:/ Hmmm... It shouldn't. I don't understand where these issues are stemming from. I'm using the current release of ATM and EVE that are on Github... You might try deleting the BoulderCo folder inside the texture cache folder.

The big benefit is that this mod will ensure all your textures get managed automatically without having to micro-manage your mods' textures. Really, it is up to you, but keep in mind that this mod also gives you the ability to set scaling however you want as well.

Also, this won't require a cache update. So no painful re-loading

Yup! works just fine.

Will it be OK with the use of Unity's functionality? (Mathf, Vector, Color32, etc...) 4-1: should fix the issues seen with EVE and other mods. https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-1

This was a silly omission on my part. Should be fixed in the next version. Also working on trying out the Nvidia Texture Tools converter. Seems faster, but not sure. If you want to try it out, you can try it here: https://github.com/rbray89/ActiveTextureManagement/tree/71786a492b7d5fe0b6a0a56b2081ba748fd64fa0 (look at the file list and choose a release zip file). Then you'll need to edit the main config (boulderCo/ActiveTextureManagement.cfg) and add an item like "USE_NVIDIA=true"

Probably is actually... Heck, if I were able to make the implementation a compute shader, or hook into the vector processing power that the graphics hardware has the conversion could be done in minutes EASILY. This is my guess what the DX stuff does.

It cheats The problem is that it links Microsoft DirectX libraries and uses conversion mechanisms from it (likely optimized, machine-code or graphics driver conversion), and I want all my mods to be platform agnostic.

This makes sense.

These are all really odd issues. My suggestion would be to try deleting the cache folder for "Atmosphere" and/or "clouds" and see if that fixes it.

Still working. HAD to get the ATM thing taken care of though. Back working on EVE.

Could you do a screenshot of the directory? I'm thinking that it wasn't cleaned up properly...

Sorry? Not sure I follow. It will take a while to compress. Also: how fast was the DDS conversion tool? I am using pretty much the same library (ported) so there may be room for optimization if I knew there were gains to be had.

Yes/No. If a mod ships with DDS textures, you'll need to use DDS loader for those, but otherwise, yes. You don't need to convert existing textures to DDS.

Haha, I have considered disabling old releases... was 1.10.2 linked to an older KSP release?

Nothing seemed out of the ordinary in the log. EVE has always been kind of finicky (especially when trying to install AVP on top of it), so I will try tinkering more over the next day or so... Hmmm... weird... what is inside GameData/ActiveTextureManagement/textureCache/ ? I tested it with the upcoming release of EVE, and it worked there just fine... Did you restart it after loading it the initial time?

It has been released! There *shouldn't* be issues with EVE, Though I've been primarily testing with the upcoming EVE release. The memory footprint should be smaller than usual, without any negative side effects I believe. You won't need to back up the cache, it will automatically check the hash files against the originals at load, so if it detects modifications, it will re-cache textures. The only annoying thing is that it could increase loading times a bit while you make changes, and you may want to restart after the initial re-caching.

Configs will work just fine

All loading times? The first should be long, but all others should be stupid-fast. I'll keep that in mind if I ever go into politics.

So it is good enough for a release you guys think?

Again: You might need to run it multiple times... it uses a bit more memory to cache, so it could crash while caching. If that is the case, just start it up again, and it will pick up where it left off.

So if no one has major issues, I'll probably try to decrease the initial loading time, but after that, we will be releasing!