chuck_starchaser wrote:LOL; I didn't know about Gimp using hardware. I will try with nvcompress; never used it before. (DAMN! I've converted lots of stuff using Gimp...)
Anyways, these 2048 x 1024 backgrounds are for bases; they don't have mipmaps. Just to clarify.
And, I'm not sure if this is related; someone just reported slowdowns after updating to the latest PU revision, with all the new DDS textures.
http://wcjunction.com/phpBB2/viewtopic.php?p=7266#7266
Any way to know if software mode is being used from stderr or stdout?
And, BTW, I did instruct users to delete /.pu/textures/backgrounds
Is there a reason they should delete anything else? I have NOT updated any unit textures to DDS. Only sky backgrounds and base textures and animations ... and planet textures.
light maps are generated, this is always going to be png. They are not Seen in the game, but they make the background ambient light on your ship. The dds textures are used for all visual display of backgrounds. The generation of the light map uses software decoding to create the png. This is a one time process per backgound loaded.
There is an easy way to tell if he's hitting software dds, just check ram usage. Software dds for dxt1 only occurs if dds hardware is not found, so we'll be using a TON of ram. If he's got close to 1GB or more allocated for VS, then he's all software.
If your cockpit images are dxt5, then he may have an nvidia card that is blacklisted. This will kick back to software. This will be significantly slower if we're software decoding large images.
The only other situation i can think of that would slow things down significantly, is if his hdd is so slow, that it takes more time to read the larger dds file than to decode the more complicated png/jpg, then generate mipmaps, then re-compress to dds. This could happen if your hdd was very slow, but you had a crazy fast video card and cpu/ram. Strange combo.
Ask him if how fast pre-dds loaded. Maybe even 0.4 (though it's not a direct comparison). DDS brought load times down from minutes to less than half a minute.. If the DDS file size is to blame, he should have actually measured a slower start time after dds files were added.
Keep in mind also, the texture sizes you are using are huge. If the after update he used images were much larger in resolution, than that would be significant.
Check his ram usage by VS, with an all stock pull (no Fing around with directories like he's doing). If it's high then this is solved. If it's low, then lets get some real numbers. He may just be imagining it, thinking the filesize must take longer to load, cuz it's bigger.
In no way have i heard that dds takes longer to load than pre-dds. Hell, even software should be faster, as it's simpler than png.
I can alleviate some software dds time by not reading in mipmaps if we have no s3tc support. But that would be a rare situation. Most people support s3tc.
make him run glxinfo too and see if it's saying he has s3tc compression support.
ps: I didn't hear anyone complain about VS taking longer to load after i made things DDS. If the larger filesize of dds is to blame (and it's always larger because we have mipmaps), then we would have seen many people complain that it's taking longer to load than pre-dds did. Never happened. The idea is almost impossible to imagine. Maybe he's loading the game over nfs, or has such little amount of ram his OS can't precache anything and his hdd is slow as hell. I'll stop speculating till we have real info.
Ed Sweetman endorses this message.