RE: [Algorithms] terrain texture again

[Phil T. <ph...@mi...>]

The original question was specifically for on-line/dynamically generated
textures, which means you have to generate the mipmaps on the fly.

This is why the original question was about doing this quickly and
possibly hardware accelerated.

Now if the speed that the terrain is being traversed at is not high
relative to the size of the textures then you can spread out the texture
creation and mipmap creation over several frames and possibly do
something that takes more time but has higher fidelity.

-P

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...] On Behalf Of
Jonathan Blow
Sent: Wednesday, July 09, 2003 1:50 PM
To: gda...@li...
Subject: Re: [Algorithms] terrain texture again

> Or just use an MMX shrink-blit as someone suggested - the advantage of
> the above methods is it's less likely to completely stall the render
> pipe. But only slightly less. :-)

Gamma correction is worth a lot, mipmap-quality-wise.  I found it to
be more important than the shape of the actual filter.  Whereas you can
do a good gamma-corrected shrink on the newest, nicest graphics cards,
I think that for overall portability it's just best to have things be=20
precomputed whenever possible (which is almost all the time).

I find it difficult to imagine an MMX loop that does good gamma
correction
that is also fast enough to justify use of MMX...

... of course if you don't really care about mipmap quality, the above
is
moot.

   -Jonathan.


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188