Quote:Original post by SweetToothKane
I'm curious if there is a way to merge two JPGs when they are loaded into one LPDIRECT3DTEXTURE9. The specific case would be a diffuse and alpha texture.

I guess you're asking this because you're using the D3DX framework facilities. If you have jpglib running, simply processing the returned data would be enough.

Quote:Original post by SweetToothKane
Two JPGs would be much smaller in file size than a DDS with an alpha channel and the extra load time (I assume there would be for two textures and combining as opposed to just one texture) would be well worth it in this instance.

When it comes to disk, you're speaking about tens of gigabytes of availability. By saving a few bytes (or even megabytes) you save virtally nothing.
Also, when it comes to disk, don't really think you can save much perf, especially when requiring to open multiple files. Opening a file on NTFS volumes can take a lot of time. Furthermore, no matter how you optimize it, the disk isn't a performance path anyway.

Quote:Original post by Krohm
When it comes to disk, you're speaking about tens of gigabytes of availability. By saving a few bytes (or even megabytes) you save virtally nothing.
Also, when it comes to disk, don't really think you can save much perf, especially when requiring to open multiple files. Opening a file on NTFS volumes can take a lot of time. Furthermore, no matter how you optimize it, the disk isn't a performance path anyway.

IMO that's the kind of thinking that leads to 20GB games and loading times of a minute or two per level.

Although I agree with the actual answer. For now, I'd suggest not giving this too much attention. You might, for example, decide later that using DXT compressed textures is the best way, and you won't want to create that at runtime. So for now don't try to optimise too much, but build your loading system so that it's easy to change it later.

First of all, I don`t understand how can you use alpha texture compressed into JPG. From my experiments, even 100% jpg quality doesn`t give you errorless alpha texture, but your mileage may vary.

Then, there is fundamental difference between the space saved : With DXT, you save also the precious VRAM, and don`t say that there`s lots of it. There`s always a shortage of VRAM, even if you 512 MB of it, since on such cards, with clever usage of it, you could create stunning rich worlds.
Plus, you get a performance benefit, since the texture occupies just 12.5% (or ~17%) of original size, thus if driver needs to move it around, it`s faster and it should be faster to sample texels from it also (I believe that`s due to some specific chip tailored for compressed textures, but I could be wrong here).

I would suggest exploring JPG2000, since that can give you easily 20%-50% file-size of the original JPG (for the price of longer loading/initialization times) or maybe even more (i remember I got my files into 10% of JPG size, and they were still usable).

Still, how many of those textures do you have that you need to save so much space ? It seems you should fill up your VRAM faster, especially if you don`t use DXT compression.

Quote:Original post by ET3D
IMO that's the kind of thinking that leads to 20GB games and loading times of a minute or two per level.

In my opinion instead it's using 1024^2 textures... they begin to make sense only now.

Quote:Original post by VladR
Then, there is fundamental difference between the space saved : With DXT, you save also the precious VRAM...

Maybe it would be a good idea to speak about "file format" and "surface format". DXT compression or decompression isn't nearly as slow as JPG or PNG.

Quote:Original post by VladR
I would suggest exploring JPG2000, since that can give you easily 20%-50% file-size of the original JPG (for the price of longer loading/initialization times) or maybe even more (i remember I got my files into 10% of JPG size, and they were still usable).

Wow! Could you point the library?

Quote:Original post by Krohm
Wow! Could you point the library?

Unfortunately not. I googled it last time when I played with it and I don`t even remember the name of it right now.
Just google for JPEG2000 and you`re set.
There`s a license fee for the commercial usage of the package (that I used), but it was about $50 or $100, so that`s acceptable considering the gains. The free utility (as far as I remember) was very slow at decompressing. But during last 3-6 months, it`s also possible that someone came with some new implementation (I think I saw some news about JPG2000 in terms of fast and affordable plug-in/code lately).

Good to hear know, I'll take a look. Too bad we won't see libjpeg updated easily. Thank you.