   Big files or big compression?
  That's of course always the question, but I want to know what you guys think about this situation.Our game uses very high quality/resolution bitmaps. These files are... huge (25MB).When compressed by using for example JPG on highest quality (which is acceptable), these files are a lot smaller (6MB).Now my question is what to choose. On the harddrive, there is no question, the big file is the best because the JPG loads much slower, but when people want to play from the DVD, what should I use?What DVD reading speed is common for this or next year?Dirk.   
  My first question is why you're using a 25MB JPEG. Outside of an enormous terrain image I believe a texture of that size is still really slow to use.DVD speeds, I wouldn't know. I don't think most consumers in NA even have DVD drives -- it's much more common in the EU.   ;  If they want to play from the DVD, they should already understand that the game will take longer to load. That's the tradeoff.As far as texture size goes... I assume your 25 MB texture is 2k by 4k. That is many times larger than the screen. In the typical situation, the camera would have to get very close to the texture before you could see an individual texel.   ;  I can't yet tell you yet why our images need to be that big...But really, they do need to be that big. :-)Who said they are textures? :-)No I'm just wondering about the loading time.I already included a background-loading system, and from the harddrive this works perfectly. The images are almost always ready to use when they are needed.But on DVD, this is not the case.So I am now trying to figure out if I should enable a minimal installation option of the game where the large files are on DVD or not.Dirk.   ;  It's already been mentioned that you probably don't need something of that size (that's a huge texture). Anyway, the compressed version will probably load faster, even with decompression because, in general, file I/O is one of the slowest things you can do, especially from optical media.   ;Quote:Original post by scippieBut really, they do need to be that big. :-)Logically they don't need to be that big, because you can't fit 25 MB of image on a screen. Even if they were scrolling, it would be a stupid idea to store them as entire images rather than breaking them into pieces for storage.   ;  So what format are the 25MB images in?   ;Quote:Original post by SneftelQuote:Original post by scippieBut really, they do need to be that big. :-)Logically they don't need to be that big, because you can't fit 25 MB of image on a screen. Even if they were scrolling, it would be a stupid idea to store them as entire images rather than breaking them into pieces for storage.They might be using it for terrain height map, or a texture atlas, or perhaps they do require this kind of resolution (maybe they texture map a big object, like a long wall, with a single texture), however, unless I'm mistaken, all pre-X1xxx ATi cards don't support anything bigger than 2048x2048. This must be taken into consideration.Anyway, how many of those textures do you have? Each texture uses at least 6MB of disk space and up to 25MB (!) of VRAM. Ask yourself whether this is indeed what you need.   ;Quote:Anyway, the compressed version will probably load faster, even with decompression because, in general, file I/O is one of the slowest things you can do, especially from optical media.Amen. If you read via asynchronous IO, you can decompress in parallel with IO. Any decrease in the disk size and therefore transfer time can be had for free. See paper for more details.   