.dds Terrtex patches. - Elvas Tower

I will attempt to clarify some points about ACE, BMP and DDS.

None of these are really image formats insofar as the image data are actually concerned. They are container formats. The image data might be 32-bit, DXT1, DXT3, DXT5, et cetera. Which container format is used depends on what the game can read, but a DXT3 extended bitmap in MSFS is really not that different than a DXT3 DDS file in MSFS (aside from the origin). ACE could probably handle lots of image formats, but the tools limit export to what MSTS used, as anything else was simply impractical. Open Rails, however, isn't bound by the limitations of the tools used to export in ACE format because it can also read DDS format. DDS is a "standard" format just like BMP, meaning a variety of off-the-shelf paint programs can export in the DDS container format. This has the side benefit of being able to export images in pretty much any format you like.

This is, in fact, the primary advantage of DDS format. Some developers will claim performance benefits, but the only performance benefit to DDS format is purely hypothetical, and it comes from the fact that DDS can have the origin set to the top left, which means you could hypothetically get a small performance benefit on loading large numbers of textures as the GPU doesn't have to flip the image like it would with a bottom left origin (UVW mapping has a top left origin). But nobody's actually demonstrated a tangible difference in an actual game to my knowledge. I think this is a "loud pipes save lives" thing - the people saying it know it's not the reason they have loud pipes (they just like the noise), but it provides a convenient and plausible argument that obfuscates the actual motivations because very few people like to admit the real reasons that they like doing things. The reasons developers really use DDS are:

1. You can export the image data in any format you like directly from your image editor without using clunky conversion tools - time is money
2. You can make payware content without paying licensing fees to use community-based image export tools

The latter is of utmost importance because the image tools that come with MSTS cannot export high-definition textures in every format, meaning large textures require the use of AceIt or TGATool. So it's probably best to not think in terms of ACE or DDS, but rather in terms of what the data actually is and what tools can export in what format. With that background, now we can talk about image data. MSTS created this horrific misunderstanding of image data for a couple of reasons:

1. It used goofy names that obfuscate the actual data being written (and the tools used to export textures are guilty of perpetuating this confusion)
2. It used a variety of bit depths but only ever displayed textures with alpha data in 16-bit (which is why textures in MSTS always look like garbage)

So most developers in the MSTS, and by extension, OR world think of images in these formats: NO ALPHA, ALPHA, TRANS, DXT1. The last one is the only honest name in the bunch. The bit depth in the colour data isn't even the same across the first three! "NO ALPHA" is a plain 24-bit bitmap. "ALPHA" is a 32-bit image. But "TRANS" is a 16-bit 5551 image. MSTS rendered the colour data for all of these images differently, with plain 24-bit images rendered correctly and 32-bit images reduced to 16-bit in the colour data (but retaining the bit depth of the alpha data). Open Rails, however, reads the data as it is written. And with the DDS container format, we gain the ability to use any uncompressed format, and any DXT format. So I can now cover the pros and cons of the formats we commonly use in OR:

24-bit: This is the standard image format we all know and love. 8 bits of colour data per channel, millions of colours.

Pros: Good bit depth.
Cons: No alpha data. Large file size.

32-bit: This is 24 bits of colour data and 8 bits of greyscale alpha data.

Pros: Good bit depth, gradient alpha allows for partial transparency and anti-aliased alpha cutouts.
Cons: Huge file size!

16-bit 5551: 5 bits of colour data for each channel, 1 bit of alpha data (black and white).

Pros: Reasonable bit depth. Reasonable file size.
Cons: Limited colour data means textures need to be dithered or there will be noticeable banding. 1-bit alpha is only really good for perfectly square cutouts as it will look jagged otherwise.

DXT1: I don't remember the texhnical details, but each 4 x 4 pixel area is reduced to a limited colour palette (4 colours for 16 pixels). 1-bit alpha channel is available but not required.

Pros: Offers a much better apparent bit depth than 16-bit, greatly reduced file size compared to 24-bit.
Cons: Each 4 x 4 pixel area is reduced to 4 colours, so artifacts may occur. 1-bit alpha is still poorly-suited to most applications.

DXT3: Like DXT1, but allows for a limited amount of alpha gradient with a 4-bit alpha channel.

Pros: Better apparent bit depth than 16-bit, gradient alpha is better suited to most applications than 1-bit.
Cons: Larger file size than DXT1. 4-bits of alpha data is still limiting when dealing with subtle or complex gradients in the alpha channel.

DXT5: Colour data is the same as DXT1 and DXT3, however, the alpha data now uses a similar compression algorithm to the colour data, allowing for a greater apparent alpha channel bit depth.

Pros: Much better alpha gradient than DXT3, much smaller file size than 32-bit.
Cons: Larger file size than DXT1 or DXT3, will have artifacts when compared to a "pure" 32-bit image.

The main takeaway is this: what format you choose depends on the image data! If your image has two or three colours in it and no alpha data, there's absolutely no reason to be using 32-bit. You would be wasting disk space because you don't need the extra colour depth or the alpha channel. In fact, you should probably be using 16-bit or DXT1 without alpha! If your image has a fine gradient alpha and lots of colours in it, then your best bet is going to be 32-bit if your goal is image quality, or DXT5 if your goal is a compromise between quality and file size. If your image requires lots of colour data, more alpha data than pure black and white, but the alpha gradient is not particularly fine, then DXT3 will do.

Whether you export in ACE or DDS also depends on the application. If you're making payware content, it would be wise to stay away from the ACE format unless you are willing to pay licensing fees to use AceIt and TGATool, or you're using formats that MakeAce can handle. If you want to use DXT3 or DXT5, then you must use DDS because none of the MSTS tools export in those formats.

A similar discussion can be had about audio formats - if your sound file has no data in it above 5,000 Hz, there's no reason to use a sample rate greater than 11,025 Hz. You're literally just wasting disk space.

Elvas Tower: .dds Terrtex patches. - Elvas Tower

.dds Terrtex patches. Painting .dds Terrtex in TSRE Rate Topic:

#21 steved

#22 scottb613

#23 steved

#24 Genma Saotome

#25 ErickC

#26 Weter

#27 ErickC

#28 SVRy_Steve

#29 Weter

#30 ErickC

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users

Skin and Language

Execution Stats

Elvas Tower: .dds Terrtex patches. - Elvas Tower

1 User(s) are reading this topic 0 members, 1 guests, 0 anonymous users

Skin and Language

Execution Stats

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users