• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
EmptyVoid

Why do game companies use custom texture formats instead of the DDS format?

85 posts in this topic

I really hate when people are talking about protecting data and someone ALWAYS comes up and says a nonsense along the lines of "you shouldn't bother protecting your data because if someone really wants to get it he will be successful anyway" it is usually spewed out by people who have never finished a commercial project by themselves. The point of protecting data is not making it impossible to access but to deter most users wanting to take a peek at it, or even to steal it for their own projects, also that data comes usually from third party vendors (sounds and music) who require you to protect it before shipping the product. Should you use your own format for your game ? If you intent to go pro, then yes, there are a lot of successful indies that are doing that and have their own file format for their games and I'm not talking about a simple password protected zip.

Now when I say file format I'm not referring to the "primitive" types like a png or a dds. I'm talking about your own format wrapping those common ones, sort of like a pak system where you can pack your data in a single file, you put sounds, images, maps, etc using your own set of functions. To read/steal it someone would have to disassemble the binary.
0

Share this post


Link to post
Share on other sites
There is a major difference between protecting people from tampering with the graphics and preventing them from stealing the graphics.

Encryption might slowdown an application but adding and checking a digital signature is not that expensive.

In the end, anything digital can be copied but you can make it hard. I have yet to find a image format that contains a digital signature, so that would be a reason to invent your own format.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by ndatxcod
I really hate when people are talking about protecting data and someone ALWAYS comes up and says a nonsense along the lines of "you shouldn't bother protecting your data because if someone really wants to get it he will be successful anyway" it is usually spewed out by people who have never finished a commercial project by themselves. The point of protecting data is not making it impossible to access but to deter most users wanting to take a peek at it, or even to steal it for their own projects, also that data comes usually from third party vendors (sounds and music) who require you to protect it before shipping the product. Should you use your own format for your game ? If you intent to go pro, then yes, there are a lot of successful indies that are doing that and have their own file format for their games and I'm not talking about a simple password protected zip.

Now when I say file format I'm not referring to the "primitive" types like a png or a dds. I'm talking about your own format wrapping those common ones, sort of like a pak system where you can pack your data in a single file, you put sounds, images, maps, etc using your own set of functions. To read/steal it someone would have to disassemble the binary.

I've written my own homebrew games and sold them for profit. I've worked at independent professional software studios, and currently work for a major game corporation.

I'm going to repeat this line, only because it is true: Do not try to obscure, encrypt, or otherwise hide your data. There is no point to it. The data is virtually useless to anybody, and if they did manage to steal it, copyright law still protects it. If they modify it, it isn't a big deal, both because of copyright protection so we can take them to court if it's bad, and if it is neutral or good it amounts to word-of-mouth advertising.

I have always used my own custom data formats for countless projects, but it is absolutely not for reasons of protecting data.

So why do it?

The file formats are useful for exchanging data between programs for compatibility, but I'm not interested in that. Instead, I know the memory formats and layouts of my data as used in the final game. I use my tools to load the data to file in exactly the same format and layout that it is needed when running. When I need to load a level, I can read a huge block of data for the assets. I don't have to worry about parsing what is images and textures, what is models, what is transformation data, or otherwise manipulate or manage the data at all. I just read the type of data, it's length, and dump the entire thing into memory all at once. This cuts load times by HUGE amounts.

If it is compressed data, then it is a simple matter to decompressed the block as it is loaded, then dump the decompressed block directly into memory. Again, it loads more than just a single bit of data but a huge swath of memory. It just adds a single step to the loader, and generally helps the load time by a few percent.

Just to show the difference, when we started one project at a studio a few years back, we loaded and parsed all the asset files directly, without preprocessing them into a tool. The load time was around four or five minutes, while listening to the disk churning as each tiny file was loaded and parsed. We finally got the tool in place to preprocess the data and pack it up, and load time dropped to just a few seconds.

Load time, not protection of data, is the primary reason to pack data in custom formats.
0

Share this post


Link to post
Share on other sites
Quote:
If data obfuscation was the goal, we would see a whole lot more games that encrypted the hell out of everything, which we just don't see.


There's normal archives, and then there's Mike O'Brien Pack [grin]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
Quote:
Original post by ndatxcod
The point of protecting data is not making it impossible to access but to deter most users wanting to take a peek at it, or even to steal it for their own projects, also that data comes usually from third party vendors (sounds and music) who require you to protect it before shipping the product.

I'm going to repeat this line, only because it is true: Do not try to obscure, encrypt, or otherwise hide your data. There is no point to it.

Frob, did you read his post? I've selectively quoted the important part. It is required. It may be practically pointless, but it doesn't make it any less necessary.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Quote:
Original post by frob
Quote:
Original post by ndatxcod
The point of protecting data is not making it impossible to access but to deter most users wanting to take a peek at it, or even to steal it for their own projects, also that data comes usually from third party vendors (sounds and music) who require you to protect it before shipping the product.

I'm going to repeat this line, only because it is true: Do not try to obscure, encrypt, or otherwise hide your data. There is no point to it.

Frob, did you read his post? I've selectively quoted the important part. It is required. It may be practically pointless, but it doesn't make it any less necessary.
No, I don't need to reread it. I saw that and hoped it was addressed clearly enough.

I've worked with several companies that had the requirement. Their goal has been to simply remove it from common container formats so people don't take it.

Every one of them have been satisfied by simply packing the data in something other than .wav, .mp3, .tga, .mb, or whatever other 'original' format the stuff took.

Since that is exactly what we are doing, repackaging it for our memory needs rather than their portable formats, it tends to fill the requirement.
0

Share this post


Link to post
Share on other sites
On the protection front, has anyone considered that obscuring/hiding data may be beneficial to players? Letting them easily browse through your assets is essentially like allowing theater play-goers to see your actors dressing up for their parts.

Everyone is curious, but not everyone really wants to see.

As for the OP question, I don't use the DDS format because it's not as widely supported by the various software I use for development. The PNG format is lossless, compressed, supports transparency, and is supported by every application I've come across. It's been ideal. My game stores all resource data, including textures, into a single game data file. There's no encryption on it, but one would need to write specialized software to open it.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by EmptyVoid
So just wondering, does the png format support volume textures and cubemaps?
Volume textures no. Cubemaps can be trivially stored in any image format by storing by layting out the sides next to each other (typically in a cross shape), ala SOIL, Horde, etc.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
On the protection front, has anyone considered that obscuring/hiding data may be beneficial to players? Letting them easily browse through your assets is essentially like allowing theater play-goers to see your actors dressing up for their parts.

Everyone is curious, but not everyone really wants to see.

Quite a few games do provide them in easy formats.

Many games, even from megacorps and major publishers, have audio files directly in mp3, wma, ogg, or other formats, ready for your listening pleasure. If you look on console game disks, you can sometimes find these.

Occasionally you can find cut scenes in wma, swf, or mpg formats. Some have .bik and .smk files, which are less obviously movies for the uninitiated.

In homebrew and F/OSS games you see games that include a ton of image files, but they are very rare in larger commercial games, for reasons discussed above.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
As for the OP question, I don't use the DDS format because it's not as widely supported by the various software I use for development. The PNG format is lossless, compressed, supports transparency, and is supported by every application I've come across. It's been ideal. My game stores all resource data, including textures, into a single game data file. There's no encryption on it, but one would need to write specialized software to open it.


What applications don't support DDS then?

Also, while PNG might well be compressed it is only compressed on disk; DXT compressed images remain compressed in texture ram, which is basically 'free' AND has the added benifit of cutting down bandwidth requirements for texture sampling as well as making better use of the texture cache on the chips (again, removing bandwidth pressure). For many images, even if the compression is lossy, this doesn't matter as you simply don't notice.

Granted, not everything needs to be compressed (much like you shouldn't turn on mipmaping and AF filtering by default for all textures) but it can be a good thing to take advantage of.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
Also, while PNG might well be compressed it is only compressed on disk; DXT compressed images remain compressed in texture ram, which is basically 'free' AND has the added benifit of cutting down bandwidth requirements for texture sampling as well as making better use of the texture cache on the chips (again, removing bandwidth pressure). For many images, even if the compression is lossy, this doesn't matter as you simply don't notice.

As I said somewhere above, it doesn't make sense to compare on-disk storage formats and in-VRAM formats, since they can be converted on the fly. And it's not slower either. We have a threaded system that will load and decode a (container-wrapped) PNG on one core, while at the same time encoding and uploading the previous DXT texture on the second core. The current bottleneck of the system is the harddisk. In fact, it is even faster than the loading of precompressed DDS, since PNGs will often require less harddisk IO to load. And we have the added benefit of letting the user choose a quality compression level in the preferences (eg. when he switches from a 512MB to a 1GB VRAM graphics card...)

Oh, and btw, of course PNG can store volume textures, texture arrays, cubemaps and mipmaps.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
What applications don't support DDS then?
Pretty much anything on a Mac [smile]
Seriously, there is exactly one external tool (Aorta) which produces DDS on the Mac.

Quote:
Original post by Yann L
Oh, and btw, of course PNG can store volume textures, texture arrays, cubemaps and mipmaps.
For some definition of store. Yes, you can store pretty much any aribtrary data in a PNG wrapper, but it doesn't provide anything much in the way of support for volume textures or mipmaps - i.e. no metadata (depth for volume textures, mipmap count for mipmaps, etc.).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Quote:
Original post by phantom
Also, while PNG might well be compressed it is only compressed on disk; DXT compressed images remain compressed in texture ram, which is basically 'free' AND has the added benifit of cutting down bandwidth requirements for texture sampling as well as making better use of the texture cache on the chips (again, removing bandwidth pressure). For many images, even if the compression is lossy, this doesn't matter as you simply don't notice.

As I said somewhere above, it doesn't make sense to compare on-disk storage formats and in-VRAM formats, since they can be converted on the fly. And it's not slower either. We have a threaded system that will load and decode a (container-wrapped) PNG on one core, while at the same time encoding and uploading the previous DXT texture on the second core. The current bottleneck of the system is the harddisk. In fact, it is even faster than the loading of precompressed DDS, since PNGs will often require less harddisk IO to load. And we have the added benefit of letting the user choose a quality compression level in the preferences (eg. when he switches from a 512MB to a 1GB VRAM graphics card...)

Oh, and btw, of course PNG can store volume textures, texture arrays, cubemaps and mipmaps.


You should try compressing the DDSs on disk. So you take your texture, store it as a DDS using a lossy compression, and then compress that image using some lossless compression algorithm. It sounds weird but it should improve load times.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Yann L
Oh, and btw, of course PNG can store volume textures, texture arrays, cubemaps and mipmaps.
For some definition of store. Yes, you can store pretty much any aribtrary data in a PNG wrapper, but it doesn't provide anything much in the way of support for volume textures or mipmaps - i.e. no metadata (depth for volume textures, mipmap count for mipmaps, etc.).

PNG supports meta data chunks. We use them very successfully to store everything I listed above, and more. The only thing PNG can't be used for is HDR/fp textures (at least not without major modifications of the format). We designed special Photoshop and Maya plugins that transparently handle the volume/cubemap/mipmap data directly without user intervention.

Quote:
Original post by Numsgil
You should try compressing the DDSs on disk. So you take your texture, store it as a DDS using a lossy compression, and then compress that image using some lossless compression algorithm. It sounds weird but it should improve load times.

We don't want our on-disk assets to be lossy compressed. Our engine is used for highend architectural visualization, and customers often complain about DXTC artifacts that are visible on smooth and subtile colour gradients, as they are used in modern interior design. So we need the option to turn off DXT compression without changing the assets.

Besides that, I'm not sure how DXTC would actually compress. DXTC is a pretty crude compression system design for speed rather than quality. It generates a lot of quantization errors that could limit the way a lossless compressor may process the data. But I never tried it. Could be interesting to do.
0

Share this post


Link to post
Share on other sites
Yann;

To be fair your requirements differ from those of games; indeed I even said that not all textures would need DXT compression.

Offline compression could also benfit from improved quality and of course more control, certainly when it comes to compressing the smaller mipmaps of the image.

But with all things no 'one size' fits all.


Quote:
Original post by Yann L
Besides that, I'm not sure how DXTC would actually compress. DXTC is a pretty crude compression system design for speed rather than quality. It generates a lot of quantization errors that could limit the way a lossless compressor may process the data. But I never tried it. Could be interesting to do.


I guess this would depend on the image as much as anything. For example given this image;

(256*256)
A 32bit PNG comes in at 7,734bytes (8,192 on disk)
DXT1 32,896bytes (36,864)
DXT3 65,664bytes (69,632)
DXT5 65,664bytes (69,632)
Now, if the DXTs are compressed via WinRAR in zip format using "Best" compression (with one file per zip) the resulting sizes (taken from WinRAR) are;
PNG 7,561 bytes
DXT1 2,738 bytes
DXT3 3,296 bytes
DXT5 3,495 bytes
With added mipmaps (9 levels);
DXT1 43,832 bytes (45,056)
DXT3 87,536 bytes (90,112)
DXT5 87,536 bytes (90,112)
And compressed as before;
DXT1 5,000 bytes
DXT3 6,029 bytes
DXT5 6,634 bytes

That image however it pretty compression friendly, with a slightly more unfriendly image such as;

(again, 256*256)
The results are;
A 32bit PNG comes in at 142,580 bytes (143,360 on disk)
DXT5 65,664bytes (69,632)
DXT5 with mipmaps 87,536bytes (90,112)
Zip compressed;
PNG 142,605 (!bigger!)
DXT5 33,287 bytes
DXT5 with mipmaps 44,227 bytes

So, yeah, YMMV but it looks like zip compression with DXTn compressed files is a good bet.
0

Share this post


Link to post
Share on other sites
I know that the commercial game 'Faces of War' uses DDS textures for there model textures. And I know this simply by looking ;)
From experience I can say: Yes, if you want to, you can reverse the data formats of most games. But until now, I only ripped data for my own projects from games that where weakly protected, because there are enough weak protected games around to not wast your time reverse engineering encrypted file formats.

But of course if you ask me, I'll always say that you shouldn't take the effort to protect your data because I personally am very curious :D
0

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
To be fair your requirements differ from those of games;

I don't think they do, actually. Although the style of the game (and its textures) surely matter, I think that it mostly depends on the player. While the intensity of texture artifacts generated by DXTC is definitely dependent on the type of textures you use, there is a lot of visual psychology involved as well.

Now, let's not kid ourselves here: DXTC is a horrible compression. The first and foremost priority with the development of DXTC was easy and efficient hardware implementation on GPUs that are now many generations old. It was not quality. Compared to other lossy systems, such as DCT or DWT based ones, DXTC is unbelievably primitive. But it can be decoded easily by GPUs, while DCT/DWT cannot (yet). This is a huge advantage - albeit its only one.

DXTC cannot be used to store work-in-progress assets during development. You need a lossless format for that, otherwise you'll kill your texture in no time due to entropy. Sure you could use DDS in lossless mode, but PNG is better in that regard (higher compression ratio, wider adoption, etc). So, if you want your engine to load compressed DDS files, you have to run a 'compilation' step on all your textures. This adds an additional time consuming and potentially error prone step to the build pipeline. If you use a lossless format, you can directly load your work textures during development, almost directly out of Photoshop. Much more convenient.

Of course, the question remains if textures should be compressed in VRAM or not. I think that this choice should be left to the player. People react very differently on compression artifacts. Some will never see them, others will be driven crazy by them. By storing textures as compressed DDS on disk, you force everyone to use the textures that you deemed compression-worthy. Even if you don't see a problem with DXTC'ing a particular image, someone else might be annoyed by the artifacts. The human brain is a strange machine :)

Also keep in mind that some shaders will greatly enhance the visibility of artifacts. Even diffuse maps that look good with DXTC in a raw state can suddenly look terrible with a particular shader applied.

So I make it a preference switch. You don't lose anything, and gain a lot. If your players upgrade their graphics card, they can turn off compression and your game will look better without any additional costs. Users with lower end cards just turn DXTC on. If some day someone manages to create a better VRAM compression algorithm either in hardware or through shaders, using it in your game is the matter of changing a few lines of code. No need to rebuild any asset.

Let me dispel another myth, that offline DXTC compression looks better than on-the-fly. This is not true. It used to be true when people compared offline with the drivers' built-in compression, which could indeed have a very bad quality. Nowadays, the driver compression has improved a lot. And if you don't like it, just use your own implementation while loading. The overhead is minimal when using multi-core plus SIMD, and the quality is practically identical to offline compressors for most of the (many) tests we did.

So in the end, I see DXTC as a necessary evil to conserve VRAM and texture access bandwidth. However, I don't see it as an appropriate format to store your textures in, because much better algorithms exist for that. Use the appropriate tool for any given job.

Quote:
Original post by phantom
Quote:
Original post by Yann L
Besides that, I'm not sure how DXTC would actually compress. DXTC is a pretty crude compression system design for speed rather than quality. It generates a lot of quantization errors that could limit the way a lossless compressor may process the data. But I never tried it. Could be interesting to do.

So, yeah, YMMV but it looks like zip compression with DXTn compressed files is a good bet.

The results are interesting. So, if you're very tight on storage space and/or have specific restrictions in that regard, then using DXTC+zip is indeed a good bet.

However, to be entirely fair, you'd have to consider JPEG as well as a storage format. Or even a DWT-based lossy compression. The figures would look entirely different then.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
DXTC cannot be used to store work-in-progress assets during development. You need a lossless format for that, otherwise you'll kill your texture in no time due to entropy.


I would argue that's what PSDs are for.

Quote:

So, if you want your engine to load compressed DDS files, you have to run a 'compilation' step on all your textures.


You should be doing this anyway. As has been pointed out before in this thread, 100 file accesses from disk is very bad for load times. At the very least you want to dump all your files in a single archive (even a ZIP will work).

Quote:

Of course, the question remains if textures should be compressed in VRAM or not. I think that this choice should be left to the player. People react very differently on compression artifacts. Some will never see them, others will be driven crazy by them. By storing textures as compressed DDS on disk, you force everyone to use the textures that you deemed compression-worthy. Even if you don't see a problem with DXTC'ing a particular image, someone else might be annoyed by the artifacts. The human brain is a strange machine :)


I would argue a different way: DXT let's you use higher resolution textures with the same file size as a smaller resolution model. That is, if I use DXT5, I can use a 1024x1024 image where a 512x512 image was before, without any additional costs in terms of performance or VRAM. DXT1 even more so. Do the compression artifacts outweigh the increase in quality from quadrupling the size of your texture? (Not rhetorical, I'm curious actually)

You could of course store the 1024x1024 textures in the game assets directory, and compress them or not at load time depending on user preferences, but it just seems like a lot of extra work to be doing during level load. Maybe if you made it an installation option. But then, you remove the ability for your artists to customize which DXT version to use. Sometimes you can get away with DXT1, sometimes you need a full 32 bit mode.

Probably the optimal version would let the artists specify an optional compression format in an options file for every texture. Then store two versions of every texture (DXT compressed or not), and let users decide which/both versions to install. But it seems like a lot of extra work still.

I think you want to avoid doing something like compressing every texture as DXT5. The different DXT versions have different strengths and weaknesses, and should really be decided by a human at some point.

Quote:
Original post by phantom
The results are interesting. So, if you're very tight on storage space and/or have specific restrictions in that regard, then using DXTC+zip is indeed a good bet.


Remember what you said your bottleneck was: hard drive access speed. That's true for every game I've ever seen (well, except for that FPS that used procedural content for everything and had an install under a couple KBs). You zip the DDSs for loading speed, nothing else really. If you can clip off 20% on average from your DDS textures, that might mean a 20% reduction in load times. Which are probably too long as it is anyway.
0

Share this post


Link to post
Share on other sites
Quote:

Quote:

So, if you want your engine to load compressed DDS files, you have to run a 'compilation' step on all your textures.

You should be doing this anyway.

For the shipping product, of course. But not during development. We used to do that, but it created a lot of annoyances and was too inflexible. The new approach has significantly increased productivity due to better rapid prototyping capabilities.

Quote:

I would argue a different way: DXT let's you use higher resolution textures with the same file size as a smaller resolution model. That is, if I use DXT5, I can use a 1024x1024 image where a 512x512 image was before, without any additional costs in terms of performance or VRAM.

Not entirely correct. Texture fetch latency and caching behaviour will be (slightly) affected, and due to more mipmap levels you'll inevitably increase memory usage (assuming DXT5).

Quote:

DXT1 even more so. Do the compression artifacts outweigh the increase in quality from quadrupling the size of your texture? (Not rhetorical, I'm curious actually)

Usually the increased resolution makes up for the artifacts. But not always. As I said above, it depends on the contents of the texture and on the person viewing it.

However, this was not my point. When you design your game and all artwork assets, you define a common lowest denominator for it to work on. Say you target 512MB VRAM class hardware. You will choose your resolutions and compression settings so to avoid (too much) swapping on such a card. Now, imagine some user buying a new 1GB VRAM card. Essentially, since your game was designed with 512MB in mind, half of his memory will be unused and the textures will look the same as on a 512MB card. Mr.NewCardOwner will not be happy. Now, of course you could distribute your game with a high resolution texture pack, but this come at a cost since it increases the size on disk and means additional work for the artists, who now have to maintain two different versions.

The alternative is to let him check a box called 'uncompressed textures', and load all (or only critical) textures without compression. It could look much nicer than a highres pack. We don't know. We can't know. Because again, the perception of compression artifacts is *very* variable from one person to the next. And doing so doesn't really cost you anything, except for a PNG loader (readily available) and a (possibly multithreaded) DXTC compressor (not too difficult to write).

Quote:

You could of course store the 1024x1024 textures in the game assets directory, and compress them or not at load time depending on user preferences, but it just seems like a lot of extra work to be doing during level load.

The overhead is minimal, as I said. The quality improvement without DXTC can be significant depending on your textures. But you don't lose the capability of enabling DXTC if needed. The only difference is that this decision is now done by the player, and not by you. Let him choose the quality versus performance tradeoff.

Quote:

Probably the optimal version would let the artists specify an optional compression format in an options file for every texture.

I wouldn't trust an average artist to handle that [wink]

Quote:

Remember what you said your bottleneck was: hard drive access speed. That's true for every game I've ever seen (well, except for that FPS that used procedural content for everything and had an install under a couple KBs). You zip the DDSs for loading speed, nothing else really. If you can clip off 20% on average from your DDS textures, that might mean a 20% reduction in load times. Which are probably too long as it is anyway.

If you think like that, then why not consider JPEG instead ? It's going to be smaller, after all. Of course there's the JPEG->DXTC transcoding, which would suck. But seriously, while the texture loading is HDD limited, it only makes a small percentage of the overall loading time of a scene.

I just can't understand how people can store their assets in a format that was never meant to be a lossy image storage format. It was designed as a compression with a GPU-friendly decoding process. It is good at doing this for now, but why use it for something where other, better alternatives exist ?

As a counter example, consider JPEG. That's a lossy format that was specifically designed for image storage. It cannot be decoded on a GPU (not yet). But it is both significantly smaller and higher quality than DXTC for stored images. Because that's what it was designed for.

Oh well, I'm actually a little obsessed with quality. I'm one of these people who find 128kbs MP3s absolutely unbearable, who are incredibly annoyed when the friends you were on holidays with send you some memorable snapshots as jpegs with a 60% quality level. That's why I cringe at the mere thought of someone using such a terrible compression system as DXTC to store textures. We all want full 32bit pixel shaders nowadays, we store normalmaps with 16bit per component precision, and so on. Yet we brutalize our textures in such a way without an option to switch it off if you don't need it ? Nope, not for me [smile]
0

Share this post


Link to post
Share on other sites
Sorry, I wasn't able to jump in when I should have responded.

Quote:
Original post by frob
Quote:
Original post by Kest
On the protection front, has anyone considered that obscuring/hiding data may be beneficial to players? Letting them easily browse through your assets is essentially like allowing theater play-goers to see your actors dressing up for their parts.

Everyone is curious, but not everyone really wants to see.

Quite a few games do provide them in easy formats.

Many games, even from megacorps and major publishers, have audio files directly in mp3, wma, ogg, or other formats, ready for your listening pleasure. If you look on console game disks, you can sometimes find these.

Being exposed to the internal resource assets of your game will almost certainly make the objects that are built with those assets feel more fabricated to your players. Your characters will seem less alive, and your world will seem more nuts & bolts. A high number of games ignoring that issue doesn't make it any less damaging. Especially in this era, where every game player is an aspiring game developer.

Quote:
Original post by phantom
What applications don't support DDS then?

Paint Shop Pro was one. Not sure, but I think 3D studio as well. I found a plugin for PSP, but it was pretty cumbersome. Something about the way it handled mip map viewing/editing.

However, I don't really want to add to the debate. At the time I chose PNG, DDS wasn't even around. PNG was the only 24+ bit transparency-capable format I could find that saved and loaded identically in every application. TGA and others seemed to be handled differently, depending on the application.

Quote:
Also, while PNG might well be compressed it is only compressed on disk; DXT compressed images remain compressed in texture ram

Any format can be compressed once its in ram. IIRC, DirectX actually has the ability to load a PNG and save it as DDS, or vice versa. Once the texture is in ram, all format bets are off.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
I just can't understand how people can store their assets in a format that was never meant to be a lossy image storage format. It was designed as a compression with a GPU-friendly decoding process. It is good at doing this for now, but why use it for something where other, better alternatives exist ?

In an ideal world, you'd store and ship all your textures uncompressed and have the user chose whether or not they want to use a compressed version if they have a lower end graphics card. But at the end of the day, your shipped title has to fit on X (which is often 1) many DVDs. The space difference between uncompressed and compressed textures is actually quite significant. On our last game it was somewhere around a few gigabytes, and with all the other large assets on disk (bink movies, sounds, music, models, etc.) something had to give. At that point it makes a lot of sense just to go with something like DXT5, since it's a native DirectX format that can easily be loaded and passed directly to the hardware. No need to load and decompress another format, then potentially re-encode it to DXTC, which increases load times (that we didn't have) either way. Like all things, it's a trade-off, so it really isn't fair to make statements like "Why can't everyone just do things like X?" We want to but we can't! [wink]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
Quote:
Also, while PNG might well be compressed it is only compressed on disk; DXT compressed images remain compressed in texture ram

Any format can be compressed once its in system ram.
IIRC, DirectX actually has the ability to load a PNG and save it as DDS, or vice versa. Once the texture is in ram, all format bets are off.
^^fixed to show apples and oranges ;)

If you're loading in one format and performing a conversion in system ram, then it increases your load texture processing times, which may increase load times. DXT is good because you can pass data straight from disc through to the graphics card with no conversions (assuming you haven't done something clever like ZIP up your textures ;) )

[Edited by - Hodgman on August 28, 2008 11:39:48 PM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
Like all things, it's a trade-off, so it really isn't fair to make statements like "Why can't everyone just do things like X?" We want to but we can't! [wink]

Well, you brought up a valid reason to use DXTC precompressed textures. You are absolutely right, sometimes you don't have the choice, and sometimes it actually is the right thing to do. On the other hand, many people, especially indie developers, have much more freedom of choosing potentially superior alternatives. That's why I was a little surprised that some people here presented DXTC precompressed assets as the only and optimal way. I found it also very misleading that people made it look like using compressed DDS files was the only way of getting DXTC compression on the GPU - which is blatantly wrong.

Quote:
Original post by Hodgman
If you're loading in one format and performing a conversion in system ram, then it increases your load times.

No, it doesn't have to. In fact, it can actually decrease loading times.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann LNo, it doesn't have to. In fact, it can actually decrease loading times.
You're right; I should qualify that by saying it increases processing time, which may not be a problem if the disc is the bottleneck ;)
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0