On Tue, Aug 05, 2003 at 12:43:51AM +0200, Ove Kaaven wrote:
> I don't buy this argument. ValidateDevice doesn't do a lot of explaining
> either. The interface it presents is not hard to implement. I'm only
> asking for knowing at runtime that with the current environment, a
> fallback kicks in. *Why* it kicks in is secondary and can be checked
> at development time with the debugging techniques you already
> mentioned, but when the game is finished and deployed, only *whether*
> the fallback kicks in really matter.
That's a common request of OpenGL programmers and a common
misunderstanding spread by Direct3D programmers (because of
capabilities and the like). Checking the extensions string reported by
the driver you might see GL_EXT_texture3D. Many OpenGL programmers ask
immediately "is that software or hardware?" The correct answer is "who
cares?" What you want to know is if that's fast or not. With or
without Direct3D-like capabilities, you *have* to code multiple
rendering paths (and this is the misunderstanding spread by Direct3D
programmers, many seem to think that capabilities saves them from this
"redundant" work, which is utter bovine excrement). The question is
_not_ "does this rendering path run in software or hardware" but "if I
take this path, can I still call this interactive rendering?" And the
only reliable way to do that is to try the path. It's really not that
hard:
for each rendering path
is the path supported?
measure path performance
select best path according to predefined criteria
and predefined criteria can be something like:
* Best absolute performance (you end up with oh,-not-so-feature-rich
paths, but some users want that)
* The path with the most features which still delivers more than N
fps
The only question is how to get a reliable measuremnet of the path's
performance. If initialization time is an issue, you can move the path
selection into the loop and use the second criterion (i.e. "if the path
manages more than N fps I'm happy, break")
Point is, you have to render. No ammount of capabilities and
ValidateDevice non-sense is going to be able to tell you that rendering
large multitextured polygons brings the whole thing to its knees
because the CPU can't send geometry fast enough or because the card
can't rasterize fast enough.
Marcelo
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
