Mesa Kills Old Hardware Support: No More 3dfx Voodoo

[curaga]

But the better compressing ones are lossy. Paletted can be lossless.

[Silverthorn]

It's quite possible that some mobile GPUs may support the OES version of the extension (which is quite different than the old desktop one) but I don't know how universal that support is.

Note that regular texture compression can net you larger gains than 8bpp textures and with much higher color depths to boot (i.e. s3tc compresses 24bpp images down to 4bpp). Alternatively, you can emulate paletted textures in shaders and enjoy much higher flexibility than driver emulation: maybe your sprites only need 4bpp? Or 10bpp? Translucency? Shaders can do all that.

I believe s3tc compresses 5-6bpp and not the full 8bpp.

[Silverthorn]

But the better compressing ones are lossy. Paletted can be lossless.

Actually, each block (4x4 pixels) of a s3tc compressed texture is stored with its own palette. This allows the decomposer to quickly locate and decode any given pixel without having to access memory in multiple locations.

[BlackStar]

I believe s3tc compresses 5-6bpp and not the full 8bpp.

s3tc works like this: it takes a 24bpp or 32bpp image and compresses it down to 4-6bpp (depending on whether the alpha channel is kept). This is a lossy compression, so some information is lost in the process. However, you cannot compare a 4bpp uncompressed image with a 4bpp s3tc image - the latter can contain much more detail than the former, despite having the same size. The 4bpp s3tc image can contain more detail than even a 8bpp or 16bpp uncompressed image of the same dimensions.

But the better compressing ones are lossy. Paletted can be lossless.

Indeed. But the only place where paletted will be better than lossy s3tc is hand drawn pixel art. (And if that's what the game contains, you can achieve better quality and lower VRAM usage with a shader instead of the 1998-level GL_EXT_paletted_texture extension.

[Silverthorn]

s3tc works like this: it takes a 24bpp or 32bpp image and compresses it down to 5-6bpp (depending on whether the alpha channel is kept). This is a lossy compression, so some information is lost in the process. However, you cannot compare a 4bpp uncompressed image with a 4bpp s3tc image - the latter can contain much more detail than the former, despite having the same size. The 4bpp s3tc image can contain more detail than even a 8bpp or 16bpp uncompressed image of the same dimensions.

Yes, I know. It just that it's wrong to say that it takes 24bpp and compress it. The quantization
step completely throws away data during the reduction to 5-6bpp. Data which can never be restored. What is actually compress is a 16bpp image to 4bpp.
I might just be over reacting to small details. I just don't like when things are advertised as a better product than they actually are (could be read as lying).

[Adarion]

*sigh*

I understand the cleanup but still somehow it's sad to see legacy support go. But then, VIA's stuff was never really running anything besides glxgears anyway and that wasn't much better than SW rendering. Well, time goes by. But if it helps to make things better...

[chefkoch]

Too bad. Currently mplayers gl2 output is the only one that works well on my unichrome notebook.

Some games work okayish with it, but mostly older stuff.

[ozzyyzzo]

And Marball Odyssey which coming to Linux use GL_EXT_paletted_texture/GL_OES_compressed_paletted_texture.

Hi, i'm Ozzy coder of Marball Odyssey.

The program is *not* using palette extensions. It's also a pure OpenGL 1.x prg, no shaders. ^^

On most platforms it uses compressed textures when available (ARB / DDS,PVRTC,KHRONOS etc) or fallback to uncompressed 32bits textures.

Extensions strings that you have found into the binary are just there to check GL extensions availabilty over various devices / systems that's why there is OES set of ext mainly dedicated to mobile devices.