Hi Luis and Arno.I wouldn't argue what works or not, but we are finding that the "blurries" sometimes appear for almost no reason. I'm suggesting the reason for the blurries is already cryptically covered in the SDKs. And this is why Joe Watson has also found this to be true through trial and error. In fact, it almost seems the problem is very hard to pinpoint because the offending texture often shows just fine... it's all ( or some of ) the other textures in the scene that suffer.Regarding the VTP lines, they won't crash the sim if DXT1, mipped, is used, but they won't show the alpha as transparent unless they are 8-bit, mipped, w/alpha.Dick

Hi Dick,Good point. It is indeed a complex problem (I haven't had this problem on my PC for example, even when I tried to test a scenery of someone who had the problem).But as MS does also uses textures that are not square I think we can use them safely. For the big size textures I am not sure, as MS does not use them.

Flight Simulator has plenty of non-DXT textures, plenty of 32-bit images, plenty of 8-bit images, a load of raw (R8) textures still hanging about, large quantities of rectangular textures - and here is my favorite 512x64 pixel(!!!) image:http://forums.avsim.net/user_files/121794.jpgIf anything, one could be led to believe that there is no hard-and-fast rule. The S.D.K.'s seem vague to the extreme on this matter and one must really read between the lines (and then read again) in order to be convinced. Perhaps we could instead believe that this matter has not been completely resolved by the FS Team, perhaps for lack of time.Joe and Scott and Joachim have certainly come upon something extremely important, however. So many of the image resolution problems that have been reported from the start, and for which experts have found other solutions, may have been due to this mix of image formats. It is interesting that so many aircraft modelers and repainters happily go about mixing image formats without a care - truly, ignorance is bliss!Best regards.Luis

Hello,Small addition:When you use:-createalpha (only available with -32 option)imagetool will tell you the alpha channel is created using the RGB value of the upper left pixel of the image.(0,0 Pixel)This is wrong!!It is the lower, left pixel (0,255 Pixel) !!!I learned from Christoph Rieger (Vfr Airfields) in the Austrian FXP-forum.Funny game to discover ;)RegardsHorst

Wuth all the information above it might be helpful to reiterate that I had a single GMAX structure in an otherwise FS9 default scene. It had three DXT1 with alpha 256 x 256 maps, which were (mistakenly) not mipped. The blurries were horrendous, until I stopped the sim by right clicking to bring up the view dialog box. The scenery sharpened up instantly. Simply mipping the three maps fixed the problem and I have not seen a blurred texture since. BTW, I too wonder about the large array of FS9 textures that are not DXT1 or DXT3.

I've been wondering about that array too! In fact, I was considering doing the FPS test before and after converting them all, is that a worthwhile experiment? Using that batch syntax above, does that preserve alphas for those textures that have them already?Best,sg

Hi John.Thanks for sharing that info. That reinfoirces my guess that DXT1 and mipped is expected in most instances.Before anyone goes wild and starts changing all the formats in FS9 to DXT1-mipped, please make a backup copy of your texture folders. And remember, there may be a reason a texture is of a different format ( exteriors of planes, props, VTP line textures, clouds... )I would suggest that addons would be likely sources of formats that are not exactly right, and the defaults could possible be left alone. Many odd texture sizes and types are in the default folder, and many of the ( like .r8 ) are not used in the sim... so ignore them.Dick