[Algorithms] Game Programming Gems source codes?

Discussion:

Juhana Sadeharju

2005-06-16 08:24:21 UTC

Hello. I could not find source codes for Game Programming Gems
book series from the web? Have they been released for public
at all -- like the source codes of Graphics Gems books?

Anyone could give the source codes of books GPG 1-5?
However the source codes would help me, my work would appear
in free software.

Juhana

--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software

Jon Watte

2005-06-16 13:58:05 UTC

Permalink

The source code comes with the books. If you want the source, buy the
books; that's what they're for.

Cheers,

/ h+

Post by Juhana Sadeharju
Hello. I could not find source codes for Game Programming Gems
book series from the web? Have they been released for public
at all -- like the source codes of Graphics Gems books?
Anyone could give the source codes of books GPG 1-5?
However the source codes would help me, my work would appear
in free software.
Juhana

--
-- The early bird gets the worm, but the second mouse gets the cheese.

B***@playstation.sony.com

2005-06-16 20:05:46 UTC

Permalink

I just implemented DXT3 and DXT5 texture compression in our texture
conversion tool using a vendor-supplied library. I understand the
technical difference between the two formats (explicit vs. interpolated
alpha), but I can't see very much visual difference between DXT3 and DXT5
versions of identical textures. I was wondering what you guys use as your
"default" compressed format for RGBA diffuse/albedo textures, DXT3 or
DXT5, and why?

In case the above question isn't algorithm-ish enough, here's another: Do
you guys tend to use vendor-supplied libraries for texture compression, or
do you roll your own? While I have a general understanding of how to
decode the compressed textures, I have no idea how to encode them and
wouldn't really know where to start rolling my own. Do any of you have
any pointers to texture compression *encoding* algorithm explanations or
source code? Google comes up empty for me, and all the vendors tend to
give out pre-compiled libraries for this task without including source
code. It seems like one would use a variation on standard color
quantization type algorithms, but with enough differences to be, well,
different. So, what type of algorithms do you guys use for DXT style
texture compression if you do in fact write it yourself?

Thanks,

Brad...

Brian Osman

2005-06-16 20:15:04 UTC

Permalink

Well, I've never done it myself, but I have looked at some of the relevant
code. My understanding:

The color compression is "the hard part". Jason Dorie's code (if I'm not
mistaken) uses something approaching brute force. It turns out that the
search space and amount of work needed is much less to DXT something than to
(for example) palletize an entire texture to 4-bit or 8-bit. To solve the
color problem, you can examine each block independently, which is very nice.
And your only REAL decisions are what endpoints to use, so you're just
trying to find two 16-bit colors. Once you've picked two colors, your block
palette has a small number of entries, and those all lie on a line in RGB
space. So just pick the closest and compute a total error for the block. You
can probably use any manner of simple search algorithms to find the two
endpoints, and the error response should be fairly well behaved (to the
point that you can start computing gradients as long as you don't move too
far).

Alpha is even easier. For DXT5 it's the same idea, but you're only working
with one dimensional data. And for DXT3, you don't really have any decisions
at all. Just pick the closest 4-bit value to whatever you started with. (I
guess you could add dithering for error-diffusion, but that's an orthogonal
step to the important one of quantization in this case.)

-Brian

----- Original Message -----
From: <***@playstation.sony.com>
To: <gdalgorithms-***@lists.sourceforge.net>
Sent: Thursday, June 16, 2005 6:06 PM
Subject: [Algorithms] DXT3 vs. DXT5 texture compression.

Post by B***@playstation.sony.com
I just implemented DXT3 and DXT5 texture compression in our texture
conversion tool using a vendor-supplied library. I understand the
technical difference between the two formats (explicit vs. interpolated
alpha), but I can't see very much visual difference between DXT3 and DXT5
versions of identical textures. I was wondering what you guys use as your
"default" compressed format for RGBA diffuse/albedo textures, DXT3 or
DXT5, and why?
In case the above question isn't algorithm-ish enough, here's another: Do
you guys tend to use vendor-supplied libraries for texture compression, or
do you roll your own? While I have a general understanding of how to
decode the compressed textures, I have no idea how to encode them and
wouldn't really know where to start rolling my own. Do any of you have
any pointers to texture compression *encoding* algorithm explanations or
source code? Google comes up empty for me, and all the vendors tend to
give out pre-compiled libraries for this task without including source
code. It seems like one would use a variation on standard color
quantization type algorithms, but with enough differences to be, well,
different. So, what type of algorithms do you guys use for DXT style
texture compression if you do in fact write it yourself?
Thanks,
Brad...
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
GDAlgorithms-list mailing list
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
http://sourceforge.net/mailarchive/forum.php?forum_id=6188

Confidentiality Notice:

This message, including any attachments, may contain confidential
information. If you have received this message by mistake, please notify
the sender immediately, delete all copies, and do not distribute or use
this information. Thanks!

Jon Watte

2005-06-17 01:53:44 UTC

Permalink

If you mostly have 0 or 1 alpha, then DXT3 will look almost as good as
DXT5. For any case where you have alpha washes and fades, DXT5 will
usually look significantly superior. In fact, we haven't really found
any data where DXT5 will look _worse_ than DXT3, so we only support 1 and 5.

We use vendor-supplied libraries -- which unfortunately don't work on
Linux :-(

To do a good job yourself, you could do a (guided) full space search for
each block. It will actually terminate in finite time. You should
probably examine exactly how your target hardware chooses to decompress
the input data, and tune your search/score heuristic to the actual
behavior (rather than the documented 1/3 and 2/3).

Cheers,

/ h+

--
-- The early bird gets the worm, but the second mouse gets the cheese.

Chuck Walbourn

2005-06-16 20:49:04 UTC

Permalink

DXT3 and DXT5 give very different results in the alpha channel unless
you are using very step-oriented alpha maps. Ideally if you have no
alpha channel or only 255 vs. 0, you should use DXT1. Most artists tend
to be happier with the alpha results in DXT5 vs. DXT3 since they tend to
use smooth alpha gradients a lot, so that was the one used most often on
my last project.

-Chuck Walbourn
SDE, Windows Gaming & Graphics

Alex Vlachos

2005-06-16 21:49:43 UTC

Permalink

DXT3 gives you 4-bit alpha, meaning 16 values evenly spaced between 0 and 1
for your entire image. DXT5 gives you 3-bit alpha that is interpolated
between 2 grayscale endpoints, meaning you get 8 values linearly spaced
differently for every 4x4 block of pixels in your image. In general, DXT5
provides better results than DXT3 because most 4x4 blocks of alpha don't
cover the full 0-1 range. However, for textures that do cover that range
well, DXT3 would be better quality.

I've thought about analyzing the alpha blocks in a texture to see which
would better represent alpha based on the content of alpha, but it
permanently lives at the bottom of my priority list. I've always defaulted
to DXT5 since it represents smooth gradient alphas better.

Thanks
Alex Vlachos

-----Original Message-----
From: gdalgorithms-list-***@lists.sourceforge.net
[mailto:gdalgorithms-list-***@lists.sourceforge.net] On Behalf Of
***@playstation.sony.com
Sent: Thursday, June 16, 2005 3:06 PM
To: gdalgorithms-***@lists.sourceforge.net
Subject: [Algorithms] DXT3 vs. DXT5 texture compression.

I just implemented DXT3 and DXT5 texture compression in our texture
conversion tool using a vendor-supplied library. I understand the
technical difference between the two formats (explicit vs. interpolated
alpha), but I can't see very much visual difference between DXT3 and DXT5
versions of identical textures. I was wondering what you guys use as your
"default" compressed format for RGBA diffuse/albedo textures, DXT3 or
DXT5, and why?

In case the above question isn't algorithm-ish enough, here's another: Do
you guys tend to use vendor-supplied libraries for texture compression, or
do you roll your own? While I have a general understanding of how to
decode the compressed textures, I have no idea how to encode them and
wouldn't really know where to start rolling my own. Do any of you have
any pointers to texture compression *encoding* algorithm explanations or
source code? Google comes up empty for me, and all the vendors tend to
give out pre-compiled libraries for this task without including source
code. It seems like one would use a variation on standard color
quantization type algorithms, but with enough differences to be, well,
different. So, what type of algorithms do you guys use for DXT style
texture compression if you do in fact write it yourself?

Thanks,

Brad...

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188

Jon Watte

2005-06-17 01:57:14 UTC

Permalink

Post by Alex Vlachos
DXT3 gives you 4-bit alpha, meaning 16 values evenly spaced between 0 and 1
for your entire image. DXT5 gives you 3-bit alpha that is interpolated
between 2 grayscale endpoints, meaning you get 8 values linearly spaced
differently for every 4x4 block of pixels in your image. In general, DXT5
provides better results than DXT3 because most 4x4 blocks of alpha don't
cover the full 0-1 range. However, for textures that do cover that range
well, DXT3 would be better quality.

DXT5 also has the option of allowing an individual block to use values
0, 255, and 6 values interpolated between two arbitrary 8 bit values.
That takes care of most cases where you have partly fully opaque and/or
partly fully transparent areas within a single block which otherwise
uses semi-translucent alpha.

Also, when it comes to compressing color (I forgot to say this in my
last message), you may want to actually look at the colors used in the
neighboring blocks to reduce the amount of blockiness in your image.

Cheers,

/ h+

Juhana Sadeharju

2005-06-17 06:57:34 UTC

Permalink

Post by Jon Watte
The source code comes with the books. If you want the source, buy the
books; that's what they're for.

--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software

Jon Watte

2005-06-17 14:05:37 UTC

Permalink

Post by Juhana Sadeharju
I would then read the books myself, lend the books to other free
open source software developers who cannot afford to buy the books,
and start writing a free open source implementation of the algorithms.

I suggest you try a library; it's already set up to support just that.
They often have book order services. A university library is more likely
to want technical reference material than a city library.

However, I also suggest you read the license agreement for the source
code before you use it. Specifically, last I checked, it said that if
you don't OWN the book, you can't OWN a copy of the source.

Cheers,

/ h+

--
-- The early bird gets the worm, but the second mouse gets the cheese.

James Milne

2005-06-17 07:05:22 UTC

Permalink

Hats off to you for your audacity!

There is actually a place which may have bought the books, and would
lend them to you. It's called a library :-) If you're close to a
college/university, contact them and ask if you could join their
library.

--
James Milne

Post by Alex Vlachos
-----Original Message-----
Behalf Of Juhana Sadeharju
Sent: 17 June 2005 09:56
Subject: [Algorithms] Re: Game Programming Gems source codes?

Post by Jon Watte
The source code comes with the books. If you want the

source, buy the

Post by Jon Watte
books; that's what they're for.

(Ok, they stole the book name from Graphics Gems but not the
great idea of making the source code freely available.)
Could anyone (or you, Jon) buy the books for me?
I would then read the books myself, lend the books to other free
open source software developers who cannot afford to buy the books,
and start writing a free open source implementation of the algorithms.
Rather I would like to that anyone of you who have the books,
join us free open source developers and start incorporating the
algorithms presented in the books to free open source software.
But if you don't have time and interest, you know at least
one who has. ;-)
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
GDAlgorithms-list mailing list
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Tom Forsyth

2005-06-17 11:19:30 UTC

Permalink

Just to mention - DXT1 has two problems. First, the colour where alpha=0
must be black. Unless you're using premultiplied alpha-blending (which you
should, of course), this can cause problems with bilinear filtering. Second
- your top-level texture might be all 0s and 255s, but your mipmap levels
will have inbetween values. So DXT1 is rarely a good option. In practice, it
never seemed worth the hassle of supporting it.

TomF.

Post by Alex Vlachos
-----Original Message-----
Behalf Of Chuck Walbourn
Sent: 16 June 2005 15:43
Subject: RE: [Algorithms] DXT3 vs. DXT5 texture compression.
DXT3 and DXT5 give very different results in the alpha channel unless
you are using very step-oriented alpha maps. Ideally if you have no
alpha channel or only 255 vs. 0, you should use DXT1. Most
artists tend
to be happier with the alpha results in DXT5 vs. DXT3 since
they tend to
use smooth alpha gradients a lot, so that was the one used
most often on
my last project.
-Chuck Walbourn
SDE, Windows Gaming & Graphics

Tom Forsyth

2005-06-17 16:38:08 UTC

Permalink

I didn't mean I didn't have any support for DXT1 - it's very useful as an
RGB texture. I just don't bother supporting it as something with an alpha
channel. I have also in the past tried to look through my list of RGB
textures and my list of alpha-only textures (specular maps, monochrome
lightmaps, etc) and paired them up as a single DXT3 or 5 texture. Saves a
bit of memory on consoles, but it's a lot of work.

Some hardware does have the 3-colour mode for DXT3 & 5, some doesn't. IIRC,
ATI and nVidia disagree on this point (one has it, one doesn't), so you
can't really use it on the PC, but of course on a console you know what the
hardware does, so it's predictable.

TomF.

Post by Alex Vlachos
-----Original Message-----
Sent: 17 June 2005 08:10
Subject: FW: [Algorithms] DXT3 vs. DXT5 texture compression.
Tom,
I tried sending this via [Algorithms] mailing list but

it no longer

Post by Alex Vlachos
seems to want to talk to me.
Simon
-----Original Message-----
From: Simon Fenney
Sent: 17 June 2005 16:06
Subject: RE: [Algorithms] DXT3 vs. DXT5 texture compression.

Post by Tom Forsyth
Just to mention - DXT1 has two problems. First, the colour
where alpha=0
must be black. Unless you're using premultiplied
alpha-blending (which you
should, of course), this can cause problems with bilinear
filtering. Second
- your top-level texture might be all 0s and 255s, but your
mipmap levels
will have inbetween values. So DXT1 is rarely a good option.
In practice, it
never seemed worth the hassle of supporting it.
TomF.

That may be true for cases where you require the alpha, but when you
only need opaque textures, DXT1 is the best choice (WRT DXT3
& 5). Apart
from the bandwidth savings, DXT1 offers the additional "3 colour per
block" mode which doesn't seem to be in 3&5 (at least
according to a MS
spec I have on my PC).
Simon

Chuck Walbourn

2005-06-17 16:44:16 UTC

Permalink

Artists are rarely using transparency instead of a smooth alpha in any
case, so I can see why people like TomF don't bother. DXT1 is half the
size of DXT2-5, but the artifacts might not be worth it. DXT1 for no
alpha and DXT5 for anything with alpha probably works fine in practice.

-Chuck Walbourn
SDE, Windows Gaming & Graphics

B***@playstation.sony.com

2005-06-17 17:14:34 UTC

Permalink

Thanks for all the replies. The general consensus seems to be use DXT1
for RGB and DXT5 for RGBA.

Thanks for the help!

Brad...