A Glimpse Into 3D future: DirectX Next Preview 222
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."
It would be nice (Score:3, Interesting)
Does this mean OpenGL is finished ? (Score:2, Interesting)
Overkill? (Score:2, Interesting)
Horse, THEN Cart (Score:2, Interesting)
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.
Shouldn't hardware vendors develop processing capability, then the software vendors implement the OS support? Or maybe I'm sensitive to the Evil Empire trying to dictate other computing advances through its 'embrace and extend' philosophy.
Compare this to CPU design, however - Microsoft doesn't dictate to Intel what extensions to add onto x86. Or do they? (puts on tinfoil hat)
Re:Who cares? (Score:5, Interesting)
IMO, yes cross-platform is the way to go. If you use the right engine (Torque for instance), you get it for free, less the occasional support call. ;-)
Look at some of the top games that have been cross-platform:
See any successful games there? ;-) And even Microsoft is smart enough to do it, while trying to lock everyone else into Windows/DirectX. Pretty funny, actually...
so how are they going to feel developing for an os unproven in game development with users who are used to getting everything for free? (dont worry, i love linux, but i just dont think we should lie to ourselves)
If they get the port essentially for free, and provide it as an "unsupported" extra, they will get a ton of good press on Usenet, the web and so on, from alpha geeks. Look at the reception Baldur's Gate games get here on Slashdot. That's worth it right there! :-)
That annoying spellchecker (Score:2, Interesting)
Re:Version mania (Score:2, Interesting)
DirectX is COM-based, so it remains backwards-compatible. COM specifies that new versions of a COM component should support the older interfaces. Besides, the only time I remember that there was a drastic change in DirectX's architecture, was when they switched from DX7 to DX8 when DirectDraw en Direct3D where merged into DirectGraphics. Besides, even then you could still use the older interfaces if you wanted to.
Re:What are the real advantages? (Score:1, Interesting)
Re:Version mania (Score:3, Interesting)
Actually, you do get problems like this to a degree. When you want to get a DirectX interface, you have to go through COM+. COM+ requires that library developers (read: the DirectX dev team) tag each version of their interfaces with a unique ID, and each time a new version of their library changes an interface, it's required to return the older interface if a program asks for it. The upshot of this is, if a game asks for a DirectX n object, then DirectX n+1 has to be able to accomodate it.
So, in theory, DirectX is backwards-compatible. In practice, DirectX versions sometimes maintain the same interface but make slight changes to functionality that break older games (especially ones that have code to work around DirectX bugs that Microsoft later fixes). I know there have been a good number of games that crash or otherwise act weird when you upgrade DirectX past a certain version, but the only one I can think of off the top of my head is WarBirds (which they later fixed through a patch).
Admittedly, this doesn't happen much anymore (WarBirds was a few years ago), but it does happen.
Re:Wouldn't game companies.... (Score:3, Interesting)
But there is more then just a technological cost to bring games to market. There is the marketing, QA, tech support, packaging, distribution, etc, etc, etc, of bringing games to additional markets. And even if it was just money, (most?) game companies are fairly small outfits; the 'distraction' of other markets might be too much for overworked staff, everyone from the CEO down to coders.
While I dont think the 'Loki experiement' was fair: its clearly easier to port to other OS if you do it from day 1, not from the release date. Basicly only ID Software developes games that have a design goal of being cross platform. But the ID Software people all have more money then they can spend, there decisions are not purely business ones, and others who should/could be using ID as a prescidence know that. It would take time, money, and (perhaps most importantly) effort, to develop games for what is still unproven markets.
Since it hasent been pointed out yet, its not a OpenGL v DirectX question. DirectX is not just a 3d graphics library; it does many, many other things. While there are many OSS projects to bring the same type of libs to linux (and other !MS OSs), some sponsored by now dead Loki, DirectX is the most compleate set of libs... And while I havent coded it either OpenGL (and friends) or DirectX, Im suspect, since DirectX comes from a single source, as a whole it is more cohesive and unified then OpenGL + friends... Which isnt to say that any given DirectX component is better then alternatives, but as a package DirectX is almost definitly better then the (not existant) OSS package.
Comment removed (Score:2, Interesting)
Re:Version mania (Score:3, Interesting)
COM+ was a horrible idea based around building/managing an application by dragging & grouping COM+ components some funky control panel/application dohicky. COM+ was built on top of COM. Most people like to forget that it ever existed.
The rest of what you say is essentially correct, though not technically. All COM interfaces are required to have a unique identifier associated with them (called a GUID), not just interfaces you want to have different versions of. Normally in COM, when you want to get/create an object you call CoCreateInstance (or a variation of it) and pass in GUID of the object you wish to retrieve. You don't do this with DirectX -- the SDK has a method for each version of DirectX you can call to retrieve the correct Interface.
So in DirectX 9, you'll want a pointer to an IDirect3D9 interface, which you'll get by calling Direct3DCreate9(D3D_SDK_VERSION). D3D_SDK_VERSION is a constant defined in one of the DirectX SDK headers representing the version of the SDK used to build the binary in question; it is NOT the version of the interface you want (this ensures that you have the right headers associated with the libraries you're linking with). All of the IDirect3D9 method return "9" interfaces (ex: IDirect3DDevice9).
Technically, COM doesn't require that you use different names for different interfaces (as long as they have unique guids), but in practice it makes things MUCH less confusing to do so. In the case of DirectX, it also means you don't have to do anythink funky with namespaces (because the sdk would include items from previous versions, which would have the name name but be different objects...).