PNG supports anything you like if you care about creating your own chunks. But it’s not much more than a zip-pped tga.
Cyranose, you must not play games. Any game that was only 600 megs would be a terrible game. Most games now are at least a gig. Plus with hard drives these days 600 megs is nothing. I can get a usb thumb drive with more space then that. I just installed a 6 gig game on my computer yesterday.
I’m under the impression that massive installations can often be attributed to the developer simply not compressing any data, whether it be through compressed formats or compressed packages. Bitmaps and uncompressed .wav files are rediculous in retail products.
Here is my attempt at loading TIFF textures. Take a look if you have time. Comments appreciated. Thanks.
http://www.geocities.com/reubenhwk
[This message has been edited by reubenhwk (edited 11-05-2003).]
Originally posted by mdog1234:
Cyranose, you must not play games. Any game that was only 600 megs would be a terrible game. Most games now are at least a gig. Plus with hard drives these days 600 megs is nothing. I can get a usb thumb drive with more space then that. I just installed a 6 gig game on my computer yesterday.
Funny. I don’t measure the quality of my games by the size of their disk [usage].
I play lots of games but I try not to install the cut-scenes (often more than 1/2 the space). Still, when I look in the directories and see uncompressed targa files it makes me wince. Not only do I lose all that disk space but I have to wait for windows to load a million uncompressed files.
Avi
.dds is best in my opinion. tga and jpeg are good too. Lots of games use jpg, it doesn’t really matter.
- Mete
Originally posted by MichaelK:
[b]Is there a way to decode JPEGs directly from memory? When using jpeglib we must provide FILE pointer to the image. So I have to write the memory chunk to tmpfile() and pass it to the jpeglib. So, do You know the trick to not use disk files?
Pozdrawiam,
Michal Krol[/b]
Yes this is possible to do.
You do this by setting the src (jpeg_source_mgr *) of the jpeg_decompress_struct struct. I did this by creating a struct which contained a jpeg_decompress_struct as the first variable. You can then add any other information in to your structure that you require. You can then provide your own methods to fill the buffer and so on. These will give you a j_decompress_ptr. Simply cast the src variable to your own data structure and fill the buffer (or whatever function is being called).
It is also possible to go go the other way and write a jpeg to memory which is similar just using different structures.
If this description is unclear I could try posting an example.
Hope this helps,
Matt
If you would like to experiment yourself try using the DevIL libs.
http://openil.sourceforge.net/
These libs support a slew of formats including all of the ones discussed plus a few obscure ones. It also has an extension lib (i think its calk ilut) that can load textures into GL for your.
Yes, yes for the pure at heart nothing beats your own hand-crafted-assembly-uber-code. But for the origninal poster I suggest you imperically (sp?) test which texture you prefer. And as a bonus the DevIL libs can save as other formats if you find one that you like.
I’ve only begun to experiment with this lib and as it is open source if you don’t think its running fast enough then help them out!
-R