I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
I think I get what your saying here, about white and black being your max and min.
The answer is
simple, to my simple mind. You need to compress your max and min based uppon your
full data set.
Apply the means-extream, if applicable, to get your new max and min.
Bottom line, make Black into Br
Daniel Vogel wrote:
Yes certainly. But software decompression of textures really should
never happen in games (performance of software rasterization really
FWIW, that's how we handle support for cards that don't support texture
compression as we store our textures pre- compressed. I agree though
> Yes certainly. But software decompression of textures really should
> never happen in games (performance of software rasterization really
FWIW, that's how we handle support for cards that don't support texture
compression as we store our textures pre- compressed. I agree though that it
doesn't
Daniel Vogel wrote:
[replying to multiple people]
They also enable the old, undocumented, dead and buried GL_S3_s3tc
extension
http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
Yes, but everything there just says "unknown" - no compression format,
nothing interesting at all (except t
[replying to multiple people]
> They also enable the old, undocumented, dead and buried
> GL_S3_s3tc extension
http://oss.sgi.com/projects/ogl-sample/registry/S3/s3tc.txt
> Note that the alpha decompression of DXT5 (in txformat_tmp.h) is
> horribly broken - stupid bug, the version from the ear
Dieter Nützel wrote:
(needed for QuakeIII/rtcw, don't know about
rtcw:et). This time I haven't tested the r200 patch, only radeon so use
at your own risk.
Using 8/8/8 Color bits, 24 depth, 8 stencil display.
GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL
Initializing OpenGL e
Am Mittwoch, 14. Januar 2004 06:29 schrieb Dieter Nützel:
> Am Sonntag, 28. Dezember 2003 23:00 schrieb Roland Scheidegger:
> > ok, here it is, the long-awaited, highly controversial new patch ;-).
> > (patches against current Mesa cvs, if you used the older version you
> > need to reverse it first
Am Sonntag, 28. Dezember 2003 23:00 schrieb Roland Scheidegger:
> ok, here it is, the long-awaited, highly controversial new patch ;-).
> (patches against current Mesa cvs, if you used the older version you
> need to reverse it first).
> The radeon/r200 patches have a texture alignment problem (wit
Well well, i just tried the patched version of the CVS tree with ut2003
and it's simply great, textures are just looking fine and the game is
far more playable than it used to be, yet i had to disable TCL to avoid
having purple textures sometimes. It really would be a shame if this
patch wasn't int
Hi,
Patch is working very nicely on my 9200, textures look great in NWN.
q3a runs fine as well although I didn't play around with the texture
settings much.
Many thanks.
Regards
Steve.
---
This SF.net email is sponsored by: IBM Linux Tu
12 matches
Mail list logo
