You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(1) 
2

3
(30) 
4
(14) 
5
(31) 
6
(18) 
7
(3) 
8
(2) 
9

10

11

12
(13) 
13
(5) 
14

15

16
(12) 
17
(13) 
18

19
(2) 
20
(3) 
21
(3) 
22

23
(5) 
24
(1) 
25
(2) 
26
(4) 
27
(13) 
28
(3) 
29
(8) 
30
(5) 





From: Martin Valigursky <dream.gfx3d@gm...>  20070412 23:52:49

I did similar thing on our last project with few changes: 1. The rotation of the shadow map in world space is fixed (so say u and v axis of shadow map are always parallel with world x and y axis (ground plane)). 2. I texel align shadow map in shadow projector space ... so that when the projected shadow map moves (because scene frustum moves), texels don't slide. This way I was able to use even pretty low density of shadow map texels  even 2 texels per meter was acceptable for static geometry (on low spec machine). There was no pixel flickering at all when the camera was moving or rotating. Martin  Original Message  From: "Wolfgang Engel" <wolfgang.engel@...> To: "Game Development Algorithms" <gdalgorithmslist@...> Sent: Friday, April 13, 2007 1:26 AM Subject: [Algorithms] Othographic Light View Frustum > Hi, > I spent some time to think about the best way to generate an > orthographic light view frustum for "fullscreen" shadow maps. I > actually use code to do this since a long time but I always perceive the > resulting frustum as too big. > The idea is to tightly fit the light frustum around a slice of the > viewer's frustum. > Here is how I do it: > > 1. determine a slice of the camera view frustum > 2. calculate a near and far plane for this > 3. transform in light space > 4. take the extrema and build a bounding box > 5. found the center of this box and transform it to world space > 5. construct the orthographic frustum from this box > > By transforming to light space and then taking the extrema, you get a > box that encloses one frustum slices. The problem is now > rotation. Let's say you contruct the light view matrix upfront just by > setting up fixed x and y vectors that just follow the z == light > direction vector. If you rotate the camera view under the light what > happens is the following: the enclosing orthographic light frustum will > rotate around the camera view frustum slice, just by changing its shape. > So in worst case it would look on the figure above like a diamond. There > are two issues attached to this: the diamond is not necessarily the most > efficient form to enclose the slice and second the rotation shows up in > the result, because the render target will rotate with it. You can see > the shadow flicker because of this. > What I did now is a kind of hack: I used the direction of the camera and > the x axis of the camera and "crossproduct" them to the light > direction. The result is better than before. > > Do I do anything substantially wrong and is there a better way to handle > all this? > Maybe I am completely off here ... > > >  Wolfgang > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist 
From: <castano@gm...>  20070412 23:20:55

On 4/12/07, Andreas Brinck <andreas.brinck@...> wrote: > Hi, > > I vaguely remember reading somewhere about a method to remove the spuriou= s > greens and magentas that occur when decompressing a DXT (or any 565 forma= t) > texture. I think the idea was to multiply the green channel by 0.5 before > compressing to remove a bit and then multiply it by 2 after decompressing= . > > Has anyone tried this, and gotten it to work? Andreas, you can achieve that storing the colors in the reversible YCoCg color space. You can translate from RGB to YCoCg with the following code: Co =3D RB; t =3D B + (Co/2); Cg =3D Gt; Y =3D t + (Cg/2); s =3D Y  (Cg / 2); G =3D Cg + s; B =3D s  (Co / 2); R =3D B + Co; You will loose one bit in each of the CoCg components, since they are signed values, but o the other side you can store Y in the 6 bit component, providing more accuracy to the luminance. A simpler and cheaper alternative is the JPEGLS transform: (RG, G, BG) It might not be obvious why that works, but with the following code you can easily test that pure greys remain pure greys after the transform: for(int i =3D 0; i < 256; i++) { =09int R =3D i; =09int G =3D i; =09int B =3D i; =09int a =3D R  G; =09int b =3D G; =09int c =3D B  G; =09// Quantize/bitexpand colors. =09a =3D ((a >> 3) << 3)  (a >> 5); =09b =3D ((b >> 2) << 2)  (b >> 6); =09c =3D ((c >> 3) << 3)  (c >> 5); =09R =3D a + b; =09G =3D b; =09B =3D c + b; =09=09 =09printf("%d: %d %d %d\n", i, R, G, B); } Hope that helps! =20 Ignacio Casta=F1o castano@... 
From: Glenn Fiedler <gaffer@ga...>  20070412 22:50:25

i got my royalty check in the mail a few weeks ago, $14US  i'm rich biaatch! On 4/12/07, Juhana Sadeharju <kouhia@...> wrote: > > >From: scott <scott+gda@...> > > > >Permission was obtained from Ye Olde List Admins for the following > >offtopic posting. Please direct any questions or other followups > >directly to me. > > Before submitting article, please ask at your free will that > (1) the source code is made freely available (just like with > the Graphics Gems), > (2) the book is made freely available in PDF format after a few > years. > > Just today (what a coincidence!) I received mail from our > university library and they said firmly they will not purchase > the GPG books. > > How much money authors have made with previous articles published > in GPG books? I have this idea that I pay authors for writing > articles to Creative Commons domain. Then people who cannot > afford to buy the ever increasing collection of good gems books > (must be 18 books by now) have a change to read them. > > Juhana >  > http://music.columbia.edu/mailman/listinfo/linuxgraphicsdev > for developers of open source graphics software > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Tibor Klajnscek <tibor.klajnscek@gm...>  20070412 20:55:14

I suspect you're talking about parallel split AKA cascaded shadow maps for directional lights. We're doing a very similar thing. Though a bit different since we're using deferred rendering. What we do is: 1. Setup light space so that it's X axis is as parallel to the view Z axis as possible (cross product :) ) 2. Slice up the frustum 3. Fit a box around the slice in light space (tight around extrema and add a bit of error margin) 4. Create an ortho projection matrix from the box 5. Render shadow map for the slice 6. Render to screen using OOB box from step 3 and matrix from step 4 (positions are sampled from the Gbuffer) This is as close as I've come to a perfect fit. I guess it's good enough as it is. Also, the shadows will flicker no matter what you do when you move/rotate the camera.  Tibor Wolfgang Engel wrote: > Hi, > I spent some time to think about the best way to generate an > orthographic light view frustum for "fullscreen" shadow maps. I > actually use code to do this since a long time but I always perceive the > resulting frustum as too big. > The idea is to tightly fit the light frustum around a slice of the > viewer's frustum. > Here is how I do it: > > 1. determine a slice of the camera view frustum > 2. calculate a near and far plane for this > 3. transform in light space > 4. take the extrema and build a bounding box > 5. found the center of this box and transform it to world space > 5. construct the orthographic frustum from this box > > By transforming to light space and then taking the extrema, you get a > box that encloses one frustum slices. The problem is now > rotation. Let's say you contruct the light view matrix upfront just by > setting up fixed x and y vectors that just follow the z == light > direction vector. If you rotate the camera view under the light what > happens is the following: the enclosing orthographic light frustum will > rotate around the camera view frustum slice, just by changing its shape. > So in worst case it would look on the figure above like a diamond. There > are two issues attached to this: the diamond is not necessarily the most > efficient form to enclose the slice and second the rotation shows up in > the result, because the render target will rotate with it. You can see > the shadow flicker because of this. > What I did now is a kind of hack: I used the direction of the camera and > the x axis of the camera and "crossproduct" them to the light > direction. The result is better than before. > > Do I do anything substantially wrong and is there a better way to handle > all this? > Maybe I am completely off here ... > > >  Wolfgang > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > > 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 20:39:22

Hey Juhana, I think most authors want to be published in a book that is a good reference. Money from book royalties is not the main motivational factor :) Please note that ShaderX and the two ShaderX2 books will be made "opensource" as soon as I have managed to get the permissions from the original authors. I will try the same with all the other ShaderX books, which means the publisher needs to agree and all the authors need to agree with this.  Wolfgang P.S: proposal deadline for ShaderX6 is still open ... :) ... couldn't resist. On 4/12/07, Juhana Sadeharju <kouhia@...> wrote: > >From: scott <scott+gda@...> > > > >Permission was obtained from Ye Olde List Admins for the following > >offtopic posting. Please direct any questions or other followups > >directly to me. > > Before submitting article, please ask at your free will that > (1) the source code is made freely available (just like with > the Graphics Gems), > (2) the book is made freely available in PDF format after a few > years. > > Just today (what a coincidence!) I received mail from our > university library and they said firmly they will not purchase > the GPG books. > > How much money authors have made with previous articles published > in GPG books? I have this idea that I pay authors for writing > articles to Creative Commons domain. Then people who cannot > afford to buy the ever increasing collection of good gems books > (must be 18 books by now) have a change to read them. > > Juhana >  > http://music.columbia.edu/mailman/listinfo/linuxgraphicsdev > for developers of open source graphics software > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Juhana Sadeharju <kouhia@ni...>  20070412 19:49:39

>From: scott <scott+gda@...> > >Permission was obtained from Ye Olde List Admins for the following >offtopic posting. Please direct any questions or other followups >directly to me. Before submitting article, please ask at your free will that (1) the source code is made freely available (just like with the Graphics Gems), (2) the book is made freely available in PDF format after a few years. Just today (what a coincidence!) I received mail from our university library and they said firmly they will not purchase the GPG books. How much money authors have made with previous articles published in GPG books? I have this idea that I pay authors for writing articles to Creative Commons domain. Then people who cannot afford to buy the ever increasing collection of good gems books (must be 18 books by now) have a change to read them. Juhana  http://music.columbia.edu/mailman/listinfo/linuxgraphicsdev for developers of open source graphics software 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 15:26:06

Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 15:24:41

Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang 
From: Simon Fenney <simon.fenney@po...>  20070412 15:15:41

Andreas Brinck wrote: >=20 > I see, in this case a value of 31 in the green channel would=20 > be expanded to 127. In order to expand our 0127 range to=20 > 0255 in a pixel shader we would have to multiply with 255 /=20 > 127 then. I will try it out :) >=20 Actually, the 6bit green value, 31, i.e 0b011111, should be expanded to an 8bit value of 0b01111101 i.e 125. Cheers Simon 
From: Andreas Brinck <andreas.brinck@gm...>  20070412 14:22:02

I see, in this case a value of 31 in the green channel would be expanded to 127. In order to expand our 0127 range to 0255 in a pixel shader we would have to multiply with 255 / 127 then. I will try it out :) /A.B. On 4/12/07, Simon Fenney <simon.fenney@...> wrote: > > I can't speak for all HW vendors but it's more likely to be option "2.5": > the more significant bits are replicated into the LSBs. For all intents and > purposes, it works out to be the same as option 3. > > Simon > >  > *From:* gdalgorithmslistbounces@... [mailto: > gdalgorithmslistbounces@...] *On Behalf Of *Andreas > Brinck > *Sent:* 12 April 2007 14:39 > *To:* gdalgorithmslist@... > *Subject:* Re: [Algorithms] Spurious DXT colors > > I just realized that just multiplying with 2 might not do the trick. I > think one has to take into consideration the way the compressed green > channel is decompressed from 6 to 8 bits on the graphics card. I can see > three different scenarios: > > 1. The 6 bits are just shifted by 2. This means that you will never get > pure white. In this case multiplying by 2 would be the correct approach. > > 2. Same as above but the last bits are padded with ones instead of zeros. > This means you will never get pure black. In this case you should multiply > by 2 and also add 1 / 255. > > 3. The bits are multiplied by 255 / 63 with correct rounding applied, so > that the entire range from 0 to 255 is covered. In this case you should > multiply by 63/31 to get our truncated green value to reach 255. > > /A.B. > > Hi, > > > > I vaguely remember reading somewhere about a method to remove the > > spurious greens and magentas that occur when decompressing a DXT (or any 565 > > format) texture. I think the idea was to multiply the green channel by > > 0.5 before compressing to remove a bit and then multiply it by 2 after > > decompressing. > > > > Has anyone tried this, and gotten it to work? > > > > /A.B. > > > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Simon Fenney <simon.fenney@po...>  20070412 13:52:15

I can't speak for all HW vendors but it's more likely to be option "2.5": the more significant bits are replicated into the LSBs. For all intents and purposes, it works out to be the same as option 3. =20 Simon ________________________________ From: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Andreas Brinck Sent: 12 April 2007 14:39 To: gdalgorithmslist@... Subject: Re: [Algorithms] Spurious DXT colors =09 =09 I just realized that just multiplying with 2 might not do the trick. I think one has to take into consideration the way the compressed green channel is decompressed from 6 to 8 bits on the graphics card. I can see three different scenarios:=20 =09 1. The 6 bits are just shifted by 2. This means that you will never get pure white. In this case multiplying by 2 would be the correct approach. =09 2. Same as above but the last bits are padded with ones instead of zeros. This means you will never get pure black. In this case you should multiply by 2 and also add 1 / 255.=20 =09 3. The bits are multiplied by 255 / 63 with correct rounding applied, so that the entire range from 0 to 255 is covered. In this case you should multiply by 63/31 to get our truncated green value to reach 255. =09 /A.B. =09 =09 =09 Hi, =09 I vaguely remember reading somewhere about a method to remove the spurious greens and magentas that occur when decompressing a DXT (or any 565 format) texture. I think the idea was to multiply the green channel by 0.5 before compressing to remove a bit and then multiply it by 2 after decompressing. =09 Has anyone tried this, and gotten it to work? =09 /A.B. =09 
From: Andreas Brinck <andreas.brinck@gm...>  20070412 13:39:10

I just realized that just multiplying with 2 might not do the trick. I think one has to take into consideration the way the compressed green channel is decompressed from 6 to 8 bits on the graphics card. I can see three different scenarios: 1. The 6 bits are just shifted by 2. This means that you will never get pure white. In this case multiplying by 2 would be the correct approach. 2. Same as above but the last bits are padded with ones instead of zeros. This means you will never get pure black. In this case you should multiply by 2 and also add 1 / 255. 3. The bits are multiplied by 255 / 63 with correct rounding applied, so that the entire range from 0 to 255 is covered. In this case you should multiply by 63/31 to get our truncated green value to reach 255. /A.B. Hi, > > I vaguely remember reading somewhere about a method to remove the spurious > greens and magentas that occur when decompressing a DXT (or any 565 format) > texture. I think the idea was to multiply the green channel by 0.5 before > compressing to remove a bit and then multiply it by 2 after decompressing. > > Has anyone tried this, and gotten it to work? > > /A.B. > 
From: Andreas Brinck <andreas.brinck@gm...>  20070412 11:40:55

Hi, I vaguely remember reading somewhere about a method to remove the spurious greens and magentas that occur when decompressing a DXT (or any 565 format) texture. I think the idea was to multiply the green channel by 0.5 before compressing to remove a bit and then multiply it by 2 after decompressing. Has anyone tried this, and gotten it to work? /A.B. 