Archived

This topic is now archived and is closed to further replies.

AngelForce

Best texture format??

Recommended Posts

Ok, I''m starting making a 2D game with dx8 and I wondered, which is the best format to use for my images... TGA seems to be used quite often, but is it lossless? PNG interests my, but the decompressing seems not very easy which is best/are there better ones? ...and how would I display a fullscreen image(eg a menu) with d3d? split it into severall peaces(as you do when you scoll it) so it works with textures(max 256*256) or is there a better way? Thanks for your replies! AngelForce -- If you find any mistakes, you''re allowed to keep ''em! ''When I look back I am lost.''

Share this post


Link to post
Share on other sites
Ahh, my favorite question: How to do fulllscreen images in D3D with the 256 limit...

Well, first things first. About picture formats: I can not tell you which texture format is ''best'' because it depends on your purpose. Having ''zero loss of quality'' can be a bad thing if you wind up with too many texture, aka lots of big files on disk. So when I have to render a fullscreen background made by an artist. A JPG with reasonable compression saves disk space and nobody notices the pixel imprecisions that JPG conversion gives. Ahem, texture choices:

TGA is indeed a ''zero loss'' format, but has no compression so its big. And older versions of Paint Shop Pro can''t save the alpha channel in TGA. Gr. JPG I love for fullscreen art because you don''t notice JPG compression on artist renditions plus you save loads of disk space. Oh, a tip: Learn to use the DxTex utility that comes with the DirectX SDK. The DDS formats are native to DirectX and allow for a variety of bit depths in 16 and 32 bits. Furthermore, the DXT1-5 ''Surface formats'' are actually compressed to save disk space! (You lose lots of quality compared to a jpg though). DxTex mostly allows you to ''build'' a DDS file from TGA or BMP files, but there exists a great plug-in for Photoshop (made by NVidia) which shows your texture in various DDS formats before you save it.

...Anyway, back to fullscreen images... I find that the best way to work is to load a large fullscreen jpg in memory, create a memory-based surface holding that jpg with the format of the current backbuffer. Then it is time to create a series of 256x256 ''textures'' (again with the backbuffer D3DFORMAT) which will have their underlying surfaces filled with the large master surface data. Presto! A few quads make your large screen.

Have a look at http://www.mvps.org/directx/articles/splash_screen.htm for good example code.

=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.

Share this post


Link to post
Share on other sites
I *think* it''s possible to save a lossless jpeg, though the compession will be (substantially) less.

I would recommend using a compressed format for your game, but keeping bitmaps copies of your originals somewhere. That way if you want to change something, you won''t have to worry about cumulative loss (if this is a problem - I''m not sure).

Share this post


Link to post
Share on other sites
S3TC is widely supported.
Use DXTC tool (note that the one in DX8 SDK has a bug), to make a DDS file.

That''s easy, fast and usefull.

You don''t even need to decompress it since it''s the format the hardware will use.

-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
Ok, now I''m torn between DXTC and PNG...
PNG seems to compress more(lossless), but it will be very difficult to decompress...
DXTC seems nice, but how much does it compress?? (I read about 50%...is it true for 32Bit images?) And why does it loose quality?

And thanks for the ''How to do fullscreen images''-answer!

AngelForce

--
If you find any mistakes, you''re allowed to keep ''em!

''When I look back I am lost.''

Share this post


Link to post
Share on other sites
S3TC is lossy, becuase it approximates the image with less data than the original, but on the other hand, it has a static compression rato (50%, as you say, may be true, I don''t remember) which means you are guaranteed less data. It''s impossible to both guarantee lossless compression and a compression ratio below 100%.

Share this post


Link to post
Share on other sites
I could argue with that BrotherBob! Gif formats use lossless compression by performing a compression on the -data-. Much like Zip files do.

You .zip files work, don''t they? There ya go: Lossless compression of the file. Unfortunately .gifs aren''t directly supported in DirectX. Heh.

Anyway, a partial loss can be perfectly acceptable: 70% JPGs on most art and DXT3-4 in DDS give pretty good results, depending on the game they''re perfectly acceptable: If you''re making a MYST-style game, worry about loss a lot. If you''re making a FPS, nobody''s going to stop and stare at a shaded wall to find the slight shade discrepancy, right?

What kind of textures will you use for which game anyway? A cartoonesque FPS? A classic adventure game with good artwork?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Spacecat


You .zip files work, don''t they? There ya go: Lossless compression of the file. Unfortunately .gifs aren''t directly supported in DirectX. Heh.



Try compressing a zip file twice: The compressed ZIP will be larger.

He''s right, it''s impossible to gaurantee lossless compression on random bits. Of course, most images aren''t random bits.

Share this post


Link to post
Share on other sites
When compressing a file, you generally get some degree of compression, that is true. But you can never GUARANTEE compression in a lossless compression algorithm. Think of it like this. If an algorithm can guarantee compression and no loss of information, you could just keep on compressing the data over and over again until you have reduced the size to one single bit. But you can''t uniquely recreate any possible set of data from a single bit of information.

Share this post


Link to post
Share on other sites
Ok, thanks for all the replies!

I think I''ll use PNG for ''normal'' images(lossless and good compression) and maybe JPG for the full screen stuff.

That is, except someone has better suggestions.

AngelForce

--
If you find any mistakes, you''re allowed to keep ''em!

''When I look back I am lost.''

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

this is a great place to learn about texture formats.

Also, I''d like to point out that the TGA format does support compression. It depends upon your graphics program, but in addition to rl encoding as mentioned earlier (run length encoding) it also supports Huffman and Delta encoding techniques. That doesn''t necessarily mean they''re lossy - but it does mean you''ll need processing time for the decompression.

Personally I use OpenGL, so I need an image format who''s "image data feild" (you''ll learn about that later) can be easily changed into RGBA format. That format is so the OpenGL graphics chips in all those computers out there know how to read the texture into their memories.

The best thing about OpenGL is the hordes of documentation and tutorials out there. Endless. Seriously. But also, it ports to Macs! So what the heck.

good luck

Share this post


Link to post
Share on other sites
BrotherBob: Zipfiles do guarantee lossless compression. But one thing to know with that kind of compression is that you can ''only go so far''. You Cannot recompress again to get a smaller file! So no you won''t end up with a single bit in the end... This is why twice compressing a zip file increases the size: You get the maximally compressed file plus some header info necessary to the zip... Which gets compressed the second time round along with the data, adding size.

This is how it -essentially- works: Let''s say in a text file, you have a long series of spaces. Thirty two of them. A lossless compressor will save a tag that says ''32xSpace'' Let us say we use the @ character to oversimplify... Well, rather than 32 bytes you get one byte for the tag, another to say ''32'' and a third one to indicate the space ascii code.
Get it? Compressed file is three bytes long, but when the program returns the data to normal, it''ll give you thirty two spaces, same as the original file: Lossless compression!

Now I suspect you to be more used to JPG-style compression, which doesn''t hesitate to damage the data -a little- provided it doesn''t apparently damage the picture. (Ideally speaking, of course) By contrast, GIF format uses a lossless compression algorithm.

This is all basic algorithmics, folks.

Share this post


Link to post
Share on other sites
quote:
Original post by Spacecat
Zipfiles do guarantee lossless compression.


No, they don't. Zip files guarantee that the compression (if any) will be lossless. But they do not guarantee that there will be a compression. That's what Brother Bob meant (I guess). Lossy algorithms, on the other hand, do guarantee that a compression will take place. But they don't guarantee it to be lossless (obviously).

And the reason why 3D hardware doesn't support GIF/PNG/etc in hardware is simple: Huffman/Lempel-Ziv based compression does not allow random access to the data. You have to decompress the entire image to access an arbitrary pixel. JPEG/S3TC/etc do support more random access: you only have to decompress a small part of the image (typically a small rectangular area) to get access to an arbitrary pixel. HW assisted JPEG decompression on texture mapping units will probably be available pretty soon. If it's a good solution in terms of visual quality is a different question. Lots of people argue that JPEGs should never be used as textures, as they remove frequency parts of the image that are essential to give a good result when resampling the texture onto a 3D polygon.

/ Yann

[edited by - Yann L on October 23, 2002 5:33:52 PM]

Share this post


Link to post
Share on other sites
quote:

You Cannot recompress again to get a smaller file


... so it cannot guarantee compression, since there are cases where it won''t compress.

And there''s also cases where uncompressed data can''t be compressed. Try download a piece of random data from www.random.org and compress it. You should be happy if you can compress it even a few bytes. I have tried a few different 4k blocks of data, and none of them was compressed even a single byte. Again, if there are cases where it can''t compress, it can''t guarantee compression.

Share this post


Link to post
Share on other sites