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