Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : 3DFX -- Ignore unavailable to you. Want to Upgrade?

To: AJ Berger who wrote (13618)	7/5/1999 5:44:00 PM
From: Eric Howard	Respond to of 16960

Another view of Glide from a Tim Sweeney article on Voodoo Extreme VoodooExtreme: Ok, the real one, now that you've had a LOT of experience with Direct3D, some with GLide, and with OpenGL, what do you feel are each APIs strong points and weak points? Do you forsee JUST going with Direct3D in the future? Tim: Glide: Was a good and necessary thing two years ago, before OpenGL and Direct3D performed acceptably. Destined to become obsolete soon. Nobody working on a new engine nowadays is targeting Glide. OpenGL: The cleanest and easiest API to use. Driver quality is worse than for Direct3D, but I see hardware vendors making a serious effort to improve that. Direct3D: Has the best and fastest hardware drivers available. The API isn't very clean, but I see Microsoft making a serious effort to improve that. The big issues on my radar screen right now are 1. Future direction. OpenGL supports vendor extensions, while Direct3D doesn't. On the other hand, the hoops developers and driver writers must jump through to get extensions implemented and supported are very daunting. In reality, I see more usable API progress happening in the Direct3D arena: it'd had the cool blending mode support with separate alpha and texture combiners; the Tritech/G400 bump map embossing technique; the dot product blending operation; DX7 has cubic environment mapping, and multi-matrix blending. There are two very different approaches. On the Direct3D end, you have Microsoft pushing the API forward at a very rapid rate, which is good for progress, but you also get see some weird API decisions made in the rush. On the GL end, you have a group of hardware vendors in their 10th(?) year of making slow, steady progress on the API, and moving at a very conservative pace. 2. Texture management. Both API's suck pretty bad from a global efficiency point of view. Both API's support "driver managed textures" which are good for model-viewing type apps and Quake 1-2 style games with very small textures. Direct3D also supports "app managed textures" which I've found enable us to get significant performance improvements now (and more in the future, as we move towards a more tiered predictive rendering architecture)--though Direct3D's driver model is too opaque to do this near optimal efficiency. Both API's need to do better here, though OpenGL drivers have further to go than D3D, from what I've seen. As we saw with Unreal, and the Tribes team saw in their OpenGL port, unless you game fits the Quake model of texture usage, the drivers won't give you much performance. Regarding JUST going with Direct3D in the future, I'll strongly consider that for the next engine. My experience with both API's so far is that OpenGL is more fun to work with, but Direct3D is the better solution for producing a shippable-quality game. Eric