256 vs. 16 million colors

[Guest]

Hi,Quite trivial questions, but I'll ask them anyway, as they still have puzzled me for a long time. Has anyone noticed if 16 million colour textures compared to 256 colour ones slow down FS noticably?Question number two. Does DXT-textures automatically mean that they are converted to 256 colours?Thanks...

[arno 1]

We have had some discussions about this in our team. I use 16 bit textures and some others thought 8 bit was faster. I converted all my textures of Schiphol to test it and didn't notice a bit difference (0.1 frame or so). So I think it makes not a real difference.And about DXT, I thought they were always 16 bit.Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest christian]

3 x 8 = 24bit, not 16bit, Arno :)This really depends on how much texture and RAM memory you have. 24bit textures (16.8 mio colors) are 3 times as big as 8bit (256 colours) textures. Usually, on modern systems 24bit colours are the way to go, unless you are using really large textures and very many of them.Arno is right though, DXT is 24 bit, so you don't really have much of a choice...Cheers, Christian

[arno 1]

For photoreal textures I think 8 bit does not always give nice colors. If you photo has a lot of colors it affects the quality. But with DXT you have no choose, so MS has made it for us :).Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[Guest]

So basically if one uses DXT-textures, there is no need to make them from original textures that are 8 bit 256 colours, but instead only use original textures that are 16 million?Yes, I know that 16 million colour pictures are 3 times as large, but does that affect the loading time in the simulator with the same value? Apparently not (?).

[Guest]

Making DXT from 8 bit is not recommended. The dithering inherent in 8 bit images makes it the worst possible source for DXT. You should always use a master 24 or 32 bit image for designing and only make a DXT copy for use in FS.DXT textures are smaller (in filesize) than the equivalant 8 bit image (half the size in fact) and are stored on the graphics card still compressed. This means they will load faster and you will be able to cache a lot more of them on the Graphics card.FS won`t display any 16 million textures. 16 bit yes, 32 bit yes, 24 bit no. DXT textures are 16 bit (65536 colours).The only thing against DXT is the quality. Otherwise there would be hardly any need for the other formats.

[Guest christian]

Just out of interest:So you say DXT1 = 16bit and DXT3 = 32bit? How does that work?Obviously, DXT3 then is 8bit rgb + 8bit alpha, but DXT1 is not 8bit rgb. Seems strange to me since at least in OpenGl you'll have a 24bit texture anyway (dunno DirectX though). I'm not saying you're wrong though, I haven't hacked into the DXT format at all...Is the compression algorithm hardware accelerated?Cheers, Christian

[Guest GerrishGray]

Hi ChristianYes, DXT1 is 16bit. DXT1 Opaque is a compressed version of 565, I believe, whilst DXT1 with Alpha is a compressed version of 555-1. And the compression and mipping algorithm are, as I understand it, intrinsic with the compression built into the firmware of graphics cards. Which is a pity because the mipping algorithm uses a smoothing routine based on a 4x4 pixel sample, so you can't have unsmoothed mips as was the case with the FS7 8bit format - although Martin is the expert on this, certainly not me! There also seems to be a feature that wraps the boundary edges of the bitmap during mipping/smoothing (to enable tiling, I suppose) - you may have noticed the numerous posts about 'boundary lines' spoiling the appearance of adjacent repetitions of an image when this is done with multiple polygons rather than tiling the texture over one large polygon. (I think it is actually possible to turn this boundary-wrapping feature off in imagetool.exe by means of a switch? But Martin's DXTBmp doesn't have the option.)I had previously assumed that DXT3 was also 16bit and equivalent to 444-4 (with a 4bit 256-level alpha channel), but perhaps used a less aggressive compression algorithm. But now that you have made me think about it, perhaps it really is 32bit - which would account better for the file size being double DXT1 - Martin: can you clarify this for us?There's no particular conflict here with your accustomed 24bit colour - after all, 888-8 32bit is merely 24bit colour with the addition of an 8bit alpha channel.Getting back to the original enquiry about the FS7 8bit format - that format remains valid for hand-painted images that don't use more than 256 separate colours as opposed to photographic ones that require numerous shades. The colours themselves are actually 24bit values (plus an 8bit alpha). But the use of the indirect pallette table in the FS7 format can cause some problems in FS2002 because it is not 'native' to DirectX and graphics cards - and this is especially true if one tries to use anything more than simple on-off, index 0, transparency - in fact anything more complex for the transparency may not work at all in FS2002.By the way, Martin, I don't usually have any trouble converting 8-bit to DXT if I do it with PSP. I open the 8bit in PSP and convert it to a simple 24bit bitmap, then use DXTBmp to convert the 24bit to DXT. I find that the problem arises when one tries to convert direct from 8bit to DXT (I first tried this with imagetool.exe) - then the results can be disastrous with completely incorrect colour-matching for some pixels.CheersGerrish

[Guest christian]

Thanks Gerrish,that was a nice explanation. I wonder why MS is doing things so weird, but it's certainly not the first time. FS2002 must be one of the last modern games not using 24bit textures. Maybe the sheer amount of terrain textures would have a significant impact on older graphics cards and hence the 16bit decision?Cheers, Christian

[Guest]

Thanks for all the information!EXAMPLE1:8 bit textures (256 colours) which are made in 565-format.EXAMPLE2:24bit textures converted to DXT1 Opaque.---------Which example do you think will give the best performance and lowest FPS hit? Still the DXTs?

[Guest GerrishGray]

HiYes, this was really your original question, eh? It's often difficult to get straight answers on this forum - we have a terrible tendency to drift off down interesting discussion paths and forget all about the original question(s) :-)The DXT formats are quicker than anything else, for a variety of reasons (smaller file sizes mean quicker loading, and more likelihood of retention in the graphics card memory so they don't have to be reloaded, DirectX 'native' format means quicker processing directly on graphics card, etc.).The uncompressed 16bit formats (565, 555-1, 444-4) offer slightly better quality and may help avoid the notorious 'blurries', but at the cost of larger file sizes and therefore slightly slower performance.32bit 888-8 has the penalty of huge file sizes, therefore potentially slow. The FS2000 '8bit' palettised version (which actually allows a selection of 256 different 32bit colours) was an excellent solution for hand-painted textures but does have some problems in FS2002 - although it still works fine in the right circumstances. But because of its indirect palette, it is also inevitably slower than DXT (although the difference is not necessarily very significant).Personally, I go for DXT every time these days to get the best FPS - I can rarely see much picture quality difference on screen anyway, and take the view that this is a flight simulator, not a fine art gallery of static views, so performance matters more than ultimate high-definition picture quality.CheersGerrish

[Guest]

Thanks Gerrish. I've learnt several new things from this topic, which will result in a quite different texture format use in the future for me. As you said the difference in quality between e.g. 565 and DXT1 is not so big with for instance day textures, which normally don't have very wide palettes. Night textures represent another group, with a wide palette, and thus I normally need to use 565 as format for those. DXT will mess up the colours./Sebastian

[Guest]

ChristianDXT3=32 bit? Don`t know where you got that....DXT1 and DXT3 are identical as far as the "visible" part of the image is concerned. Both are 16 bit 565 passed through DXT compression.DXT allows 4 interpolated colours in each 4x4 pixel block.The difference is the Alpha. DXT1 uses a special switch so that when transparency is required the relevant block changes to a "3 colours + Transparent" mode. DXT3 uses a seperate 4 bit Alpha channel. To all intents and purposes they should appear exactly the same to the eye. Only the individual blocks containing some transparency will be marginally colour-reduced in DXT1.Decompression is done in hardware on most modern graphics cards. This is why virtually all games these days use a variation on the DXT format for textures. Flightsim, Trainsim, Medal of Honor etc. Look at the internals and you will find either pure DDS DXT or some closely related format being used. If not for all the textures then at least for the heavily used ones like Terrain.DXT is a native DirectX format but I would imagine that it is also supported by OpenGL. The main work is done by the Graphics card and drivers anyway.

[Guest GerrishGray]

Hi MartinThanks for replying and adding your expertise to this thread - the rest of us are just guessing half the time and need your knowledge to put things straight!I have some outstanding questions you might be able to answer:[ol][li]The first was the reason why Christian made me wonder if DXT3 used 8-bit colour channels rather than the usual 16-bit / DXT 4/5-bit - why are DXT3 bitmaps twice the size of DXT1? Is it a different, less aggressive, compression algorithm, or is it, perhaps, that the 4-bit alpha is stored uncompressed? It's not really important to know this - just interesting![/li][li]Is it possible to compile a DXT image from separately-edited mips and/or turn off the smoothing for the mips? If this is possible, it would be nice if DXTBmp could have the same facilities for turning off smoothing and/or manually editing the mips as you had in Bmp2000 for the FS70 8-bit format. The blurry appearance of the mipped images is one of the biggest problems people have with using DXT, and cause some very unfortunate effects in particular circumstances.[/li][li]Is it also possible to optionally suppress the border-wrapping of opposite edges of the image that seems to occur as part of the 4x4 smoothing process? This is fine for ground textures but causes problems sometimes with textures that contain several images on one bitmap, as often used when modelling 3D objects.[/li][/ol]Thanks again for your expert input.Gerrish

[Guest christian]

Hi Martin>DXT3=32 bit? Don`t know where you got that.... And I don't either. I should have really read your initial message properly, I thought you wrote that, but I just reread your message and you obviously don't mention anything like it. So it's just me making things up. Sorry about that, things make sense now.>DXT is a native DirectX format but I would imagine that it >is also supported by OpenGL. The main work is done by the >Graphics card and drivers anyway. I'm not a DirectX expert, hence I only came across DXT with FS2002 the first time. From the graphics side, I really only know opengl. I remember that some 'ancient' card (from S3) introduced hardware texture compression (this was after the release of Quake3Arena). The format was S3TC. I think this is what opengl still uses. DXT may be DirectX specific, but I'm not sure. I just read some geforce specs and indeed S3TC and DXT are supported by hardware...Idsoftware choose the more convenient approach of compressing the textures on the fly (they do that in Quake3 and also in Doom3). This means you have to wait a bit initialy, but can supply textures in tga or jpeg format. On the other hand FS2002 really takes a long init time already so using the DXT format directly may have to do something with keeping init times down...Cheers, Christian