Slashdot Mirror
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!
DX10 will work fine with your new card. DX has always done this. DX9 works fine with DX8 cards like the Radeon 9000/9100 and GeForce4 series.
However the cards do not have support for the new features of DX10 (like PS/VS3/4 etc). The cards can work with the new software, and do, but the hardware just isn't there.
OpenGL and DirectX are different kind of systems, DirectX offering interfaces to input devices, sound controlling etc. OpenGL is just for graphics! :)
Don't get this personal, I always post like this when someone compares these two
class he-man extends man!
Doom 3 was delayed.. again.
So DX11 will be "DirectX Try"?
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
DX9 is backwards compatible with even my lowly NV25 and MX cards.
The issue is my card doesn't have the vertex shaders and other registers that DX9 takes advantage of so i won't be fully accelerating new DX9 features. I can run DX9 games just fine even though my card was designed with 8 in mind.
Its not that it isn't backwards compatible, it is that your hardware doesn't suport technology of the future since it didn't exist
Only way around this would be if your GPU core was software driven and they could update it. Otherwise to get new DX10 support, you need a DX10 card that was built with the new functionality in mind.
Backwards compatibility has nothing to do with it. Its just like in the days of MMX vs NON MMX. IF you had MMX it ran faster, if you didn't it never wouldn't work for you.. just would be slower.
SDL does this for Linux (and several other OS's including Windows.) It uses OpenGL for the 3D portion. Unfortunately, DirectX is years ahead of SDL.
I'm no 3d coder guy but as I understand it shaders are short programs you can enter into the GPU to control how a face is rendered [at a given vertex]. Before that you used to say "render me with [phong|gouraud|flat] shading" and the whole thing looked uniform.
Shaders programs let you do cool things like features [e.g. skin, roughness to things, etc...]
What I don't get is why didn't they just make the GPU a generic RISC with say 32/32 registers [ALU/FPU] and a set of instructions that fast graphics would require [say saturated X bpp operations, fast division, etc...]
That way you have a processor you can just upload code to. Also make it a standard so instead of having "every joe and their brothers graphic processor specs...." you have something truly conforming...
Tom
Someday, I'll have a real sig.
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.
Disclaimer: I have never looked at or written a piece of code in my life that used DirectX.
However, your comment makes no sense. All games written for one version of DirectX should work in the later versions. Otherwise you'd have games failing left right and centre and people on here bitching about how they can't update DirectX without killing their favourite game.
Hell, I have a couple of DirectX 5 and 7 requiring games and they work just fine under v8 and my recently installed 9.
The only downside to the frequent updates is when you want to take advantage of all the new wizzy things the graphics cards are doing. But I don't think thats a fault of Microsoft, more an indication of the rapid pace of development (since MS merely support the things the graphics card makes tell them their next cards can do)
Avantslash - View Slashdot cleanly on your mobile phone.
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.
What I don't get is why didn't they just make the GPU a generic RISC with say 32/32 registers [ALU/FPU] and a set of instructions that fast graphics would require [say saturated X bpp operations, fast division, etc...]
This was tried in the past, with TI's TIGA (Texas Instruments Graphics Architecture) which supported the TMS34010 and TMS34020/34082 graphics coprocessors. This was a really neat architecture which accelerated 2D and basic 3D operations. Unfortunately, the CPU chip manufacturers (Intel, etc...) would identify the bottlenecks and optimise their CPU's so that the next generation chips would be faster than a current generation CPU/GPU. "Local Bus" basically whacked out TIGA from the market. A real shame, since you could write your own extensions which had complete access to GPU memory (maybe this was a bad thing). They even got as far as having a trapezium rendering algorithm (halfway to rendering triangles).
Going back to the present day, look for the extensions like ARB_vertex_program and ARB_fragment_program. According to Microsoft's plans, these will at least have identical instruction sets. I wonder how long it will be before we can completely define an entire graphics pipeline using a single program.
(This would probabl require virtual "clip_vertex", "render_triangle" function calls).
No it's not. With the approval of the ARB_vertex_buffer_object extension and GLSlang, both APIs expose about the same level of functionality. Render to texture is a mess in OpenGL right now. But there are Super Buffers/pixel_buffer_object extensions in the works. And the Super Buffers extension looks like it will cover most of the functionality that is slated for DirectX Next.
Revelant links:
http://oss.sgi.com/projects/ogl-sample/registry/
http://oss.sgi.com/projects/ogl-sample/registry/ ARB/vertex_buffer_object.txt
http://oss.sgi.com/projects/ogl-sample/registry/ ARB/shading_language_100.txt
http://www.opengl.org/about/arb/notes/meeting_no te_2003-06-10.html
http://developer.nvidia.com/docs/IO/8230/GDC2003 _OGL_ARBSuperbuffers.pdf
Note that OpenGL is usually updated once a year at Siggraph. The next version of DirectX is slated for after the release of Longhorn. That'll be 2005 or so.
Please do not perpetuate the myth that OpenGL is "falling behind" Direct3D. That is plain wrong. And a diservice to both the open source community and the graphics development community.