Is Transparency with JPG possible?
No. I recommend PNG or DDS formats, they can handle alpha channels very well. As to which one to use - PNG is good for absolute image quality, while DDS, though lossy, can be decoded on display hardware so that the memory bandwith requirement is lowered considerably.
-Nik
-Nik
JPG doesn't accurately store color information per pixel. It's a compression. What you see as white is not pure white color RGB(0,0,0) but the values are varied depending on the compression level.
You can achieve transparency with JPG but through masking, not color keying.
You can achieve transparency with JPG but through masking, not color keying.
Okay, is there any common lossy standard designed with alphas in mind? Or even better, an N-Channel system, in case you've got other non-colour texturemapping needs? The fact that the choice seems to be either jpg(lossy) or png(alpha, but non-lossy) seems to be missing a meeting of the formats.
I guess a series of monochrome jpgs could be compiled into a single zip... especially if the headers could be merged into a single file... does jpg have optimizations for monochrome images?
I guess a series of monochrome jpgs could be compiled into a single zip... especially if the headers could be merged into a single file... does jpg have optimizations for monochrome images?
Greetings!
Here how it goes: Video cards can not handle JPEGs directly, so they take the same amonunt of VIDEO MEMORY AS A BMP FILE WOULD. If you are using DirectX then definitve take DXT1 for textures and DXT3 or DXT5 for transparent TEXTURES (clouds, windows & stuff). DXT "can" show you the minimum size the TEXTURE will take in your video memory. In case you are using OpenGL try some S3TC compression formats (nVidia SDK site).
If you would be able to load a 10kb 512x512 texture, it would take at least 768KB in Video memory.
Here how it goes: Video cards can not handle JPEGs directly, so they take the same amonunt of VIDEO MEMORY AS A BMP FILE WOULD. If you are using DirectX then definitve take DXT1 for textures and DXT3 or DXT5 for transparent TEXTURES (clouds, windows & stuff). DXT "can" show you the minimum size the TEXTURE will take in your video memory. In case you are using OpenGL try some S3TC compression formats (nVidia SDK site).
If you would be able to load a 10kb 512x512 texture, it would take at least 768KB in Video memory.
Yes, for video reasons bmp makes sense, but the fact is that more and more content is being served over the net. Ever logged on to a UT server and been bogged down with downloading packages? 90% of the weight of those things is texture data. Cube uses jpeg-based graphics and is a very light download, comparitively.
Any sort of net-served content should be based on lossy textures rather than bogging the connection with pedantic ideology.
Any sort of net-served content should be based on lossy textures rather than bogging the connection with pedantic ideology.
As far as I know, the JPEG format can handle arbitrary channels and color spaces. It's just that most JPEG routines only have code for reading and writing 8 bit grayscale and 3x8 bit RGB. From looking at the source code for the Independent JPEG Group's JPEG library, I get the impression it is prepared for handling other color channel distributions as well. You need to adapt your code for that, however, and not rely on a precompiled JPEG library, like the D3DXLoadSurfaceFromFile function, for example.
JPEG isn't evil. It's pretty good, unless you are using less than 100% quality when saving.
PNG is good, but Internet Explorer 6 doesn't support colorkeying with it. (IE6 does support colorkeying with GIF)
I suggest you use Targa for game development.
PNG is good, but Internet Explorer 6 doesn't support colorkeying with it. (IE6 does support colorkeying with GIF)
I suggest you use Targa for game development.
24-bit png always seemed to make the most sense to me for game development. That alpha channel really makes a difference.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
