A Glimpse Into 3D future: DirectX Next Preview
Dave Baumann writes "Beyond3D has put up an article based on Microsoft's games developers presentations given at Meltdown, looking at the future directions of MS's next generation DirectX - currently titled "DirectX Next" (DX10). With Pixel Shaders 2.0 and 3.0 already a part of DirectX9 this article gives a feel of what to expect from PS/VS4.0 and other DirectX features hardware developers will be expected to deliver with the likes of R500 and NV50."
XBOX Next?
:)
DirectX Next?
I guess we all know what the Next version of Windows is going to be called!
if I'd bought such a card I'd be quite annoyed if there wasn't decent support for it in the future.
:)
You mean you don't upgrade your video card once a year?!
Not really, they are saying this won't be out until at least Longhorn. By the time that comes out, you can bet a LOT of games will fully exploit DirectX 9...
I could care less about this functionality being exposed through a proprietary API.
My question is: when will it be available in OpenGL 2.x? :-)
Cross platform is the best way to go with game development...and OpenGL is the only game in town for cross-platform 3D graphics. It is also the official 3D API for Macintosh.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Microsoft aren't dictating to NVidia and ATI what features to put in their next chips, either. NVidia, ATI, other card makers, and graphics programmers, are telling Microsoft what features they need in an API, and Microsoft are releasing APIs that have those features.
Compare this to OpenGL, which is lagging so far behind that only rare titles take it seriously (Doom3 is the one that springs to mind).
Note for example that both NVidia and ATI provide better support for DirectX in their drivers than they do for OpenGL. That doesn't sound like companies being imposed upon, that sounds like companies appreciating an API that supports the features they've spent a lot of money developing.
And they don't care about portability, because Linux and MacOS are basically irrelevant as gaming platforms. That's not going to change until OpenGL catches up with DirectX, guys.
The game developers are the ones who really want new performance features (sure it will make the hardware manufacturers money but the developers are the ones who are really driving it).
The game developers don't ever work directly with the graphics card, only the API. So to them extensions to performance are basically extensions to the API (and just demand that users get a card that supports the API).
The API for DirectX is of course designed by Microsoft who want people to use it because it locks them into Microsoft more than OpenGL. So Microsoft want to advance the API to please the developers. Therefore Microsoft extend the API for new future features.
Graphics card performance is not based on processing power, its based on how fast they can go while implementing the API (either DirectX or OpenGL). To get sales they need their DirectX performance to be good so they follow the API (with one eye, the other on OpenGL) and try and make the best card for implementing it.
So there's no real point having a feature on your graphics card that isn't used by the API. While OpenGL does have extensiosn to allow you to get at manufacturer-specific stuff to an extent, as I recall DirectX doesn't so much (it just provides a generalised architecture for manufacturers to implement, as core OpenGL does).
Which is why DirectX comes before the manufacturers to an extent. There's a bit of poetic licence there but that's my general view.
How about a sneak preview of how many patent licenses it will require to implement?
No, wait, that would be bad marketing. You have to get everyone excited about it first, then when everyones asking for it, the other vendors will want to use it, and *then* the patents come out.
Ah, screw all this microsoft monopoly crap. I prefer free market capitalism. Give me Free Software any day.
Expert in software patents or patent law? Contribute to the ESP wiki!
I have done some work with DirectX and the biggest problem I see is that new versions come out too quickly. Do you want your project to be totally tied to DirectX version N with you know N+1 will be out next year making your huge project obsolete or requiring a rewrite. For that reason SDL or OpenGL (an API that hardly changes) appeal to me. Who wants to build on shifting sands.
That's how it's supposed to be. The problem is that in practice, I've seen cases where the "emulation" of a vertex shader in CPU didn't work properly (a DX8 vertex shader that ran fine on GPU, but had weird problems on CPU). The solution was a line-for-line port to C++ of the vertex shader, and having a separate execution path for non-VS supporting cards. In short, a big pain in the ass to program for.
I try not to make it a habit to flame people, but do you know what you're talking about? Adding new functionality to DirectX *before* the new hardware comes out, means that when you buy your new GeForce FX 9999, you don't have to wait for Microsoft to release a new version of DirectX 6 months later to use the full potential of the card. This has absolutely nothing to do with embrace and extend. This is their proprietary graphics/multimedia API in the first place. How can they "embrace and extend" their own library?
Your second bit of anti-Microsoft conjecture is no better than your first. When it comes to Microsoft working with Intel to add extensions to the x86 processor set, so what if they did? Do you think they wouldn't benefit all x86 operating systems? At the level of the instruction set, how would you design into an x86 CPU, instructions which only benefit one x86 OS? Yes, Microsoft has worked with Intel on the instruction set, but mostly vice verca. It is Intel who releases the manuals on "how to write an OS for our CPUs." But no matter how they're working together, that is a good thing, not "the evil empire at work."
Please, learn a little and think a little before you post your knee-jerk anti-MS reaction. There are plenty of legitimate reasons and opportunities to bash Microsoft. The problem I see is a lot of people look like that guy from Can't Hardly Wait who keeps trying to find the right second to start the slow clap.
Well I hope you aren't referring to gaming companies, cause last I checked there weren't a lot of programmers using OpenGL for their graphics in games.
The fact that Quake3 is still used for measuring OpenGL performance of gaming cards says an awful awful lot about the number of game engines using OpenGL (engines based on Q3 not outstanding)
I don't think that OpenGL will be "finished" as long as DirectX only works under Windows. There are other operating systems out there and while most support OpenGL in their windowing system, DirectX is only for Windows.
If you meant OpenGL is dead in the Windows games market, I'd argue that it mostly has been for a while. Yeah John Carmack uses OpenGL, but most games are implemented in DirectX. It's not like it really even matters, though, actually rendering code is usually a pretty small portion of a game and can be ported between APIs without too much trouble (just ask people from Loki Games or icculus.org).
True story.
Compare this to OpenGL, which is lagging so far behind that only rare titles take it seriously (Doom3 is the one that springs to mind).
I can only see one property of OpenGL that is "lagging behind" DirectX: Whiz-bang features.
Is OpenGL "lagging behind" DirectX in portability? hardware support? scalability?
I would argue that OpenGL as a general-purpose 3D API is more useful than DirectX soley because it is more widespread. The API is implemented (or implementable) on a more diverse selection of hardware and software platforms than DirectX can ever dream of.
As a Intel-Windows-Cutting-Edge-Game-only API, DirectX is the way to go, but for everything else, we have OpenGL.
The people who say has DirectX destroyed OpenGL generally dont know what they are talking about. Basically both give you an interface to the graphics hardware and some legacy stuff (eg Direct X has a fairly complete software implementation of most stuff although many programs test the hardwre capabilities directly so this becomes irrelevant). There are a couple of problems with the GL interface (render to texture mainly). But there is also the "traditional" OpenGl interface, which is what most people learned, and the fixed function extensions. The traditional interface is basically the hardware stuff that SGI implemented (the stack based renderer). It is basically obsolete except as a teaching tool and for legacy code, because the hardware really doesnt look like that any more. The extensions are basically the same in many cases although some expose bits of hardware that are basically existing low level bits.
And OpenGl is falling behind in one sense: the Direct X process is the process by which there is a (moderate) amount of standardisation of what the raw hardware capabilities of different manufacturers cards are. OpenGl has no influence on this.
Neither are necessary or ideal, but things will only stabilise when the hardware designs do.