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."
If they could somehow program Dx10 so it was backwards compatiable with cards now (such as radeon 9800 etc), if I'd bought such a card I'd be quite annoyed if there wasn't decent support for it in the future.
When anger rises, think of the consequences.
Confucius (551 BC - 479 BC)
So while we wait for some great games to make proper use of DX9, we can dream of games on DX10 and only dream of the wonders of DX11.
XBOX Next?
:)
DirectX Next?
I guess we all know what the Next version of Windows is going to be called!
At this point DirectX is years ahead of OpenGL
With few, if any, games fully supporting DX9, is DX10 a bit of overkill? I'm all for the advancment of technology, but it looks like the cart is coming before the horse, and dragging the horse with it.
Doom 3 was delayed.. again.
So DX11 will be "DirectX Try"?
if theres one thing a business model can achieve, its quick and streamlined development on something as critical as directx. gnu/linux desperately needs improvement in this area
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
Doesn't this logic seem backwards?
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)
I want to delete my account but Slashdot doesn't allow it.
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.
Enlighten me.
Instead of say "ultra shade 2000 (tm)" how about "more polys render (tm)". Cuz really well drawn 2d trees/grass/foilage is getting kinda lame [no matter how high the bpp is!]
... though I recall when 15/16 bpp was dreamy] cuz I concentrate on the game, not how nicely phong shaded some poorly tesselated object looks.
Really it gets to the point where people are like I want 300fps *and* I want every pixel to be drawn perfectly.
I'd just go for decent poly/s and a card that doesn't catch on fire! Heck I play most games in 16bpp [yuck!
That and as many others said... why not use OpenGL? Or better yet. Why doesn't DirectX just act like a wrapper around OpenGL [or merge OpenGL into DX?] DX does provide input/sound support which nobody bitches about. The 3D support leaves a lot to be desired [and undesired]
Tom
Someday, I'll have a real sig.
... be better off using something like OpenGL or SDL or some other cross-platform (if not Free, free, or combinations thereof) API, if for nothing more than to make porting to Mac or consoles or anything else much easier?
Don't blame me, I voted for Kodos
"While the next major revision for DirectX is not expected until Longhorn's launch..."
Well, that means we've got at least a couple years (or a decade) for games to really take advantage of DX9. I'm glad that people will be given a chance to get new hardware that properly supports DX9 (at a mainstream price) and PLAY games that support it before we're told to upgrade again, even if it's only because of Microsoft's problems with Longhorn.
(Minor digs at MS and Nvidia in there of course).
"But I trust in the people's capacity for reflection, rage and rebellion." -Oscar Olivera
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!
"We have X's in our name, too! In fact, in our new and improved version there's twice as many X's! Just wait until our next operating system, codenamed Windex, comes out. Those Linus people ain't got nothin' on us."
If aspiration is a virtue, achievement cannot be a vice.
...but will it run on my 3dfx Voodoo 2?
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.
My web server doesn't do much 3d graphic processing
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Notice how some words, such as "OSs", are underlined by the spellchecker in the pictures. Are they too lazy to remove those?
Just another ignorant, Microsoft hating fool who was absolutely no knowledge of any of the subjects he just touched on, and who thinks he's battling the "evil empire" by pointing out Microsoft's wrongs, even when they aren't wrongs.
Oh wait, this is Slashdot, MOD PARENT UP!
sad, really.
but can i run it from linux?
seriously. i wonder if the next generation computing has drm involved with the directX. and by the way i dind't RTFA becuase.... well i'm lazy
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.
What is the real advantage of using DirectX instead of standard OpenGL? I'm going to start a little project soon and I have to decide what tools to use. Are there any problems with OpenGL support on Microsoft systems or what?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
At Nintendo, we have been surprised that no major graphics vendor has really addressed to an adequate degree this problem, so we're currently spearheading the development of a new architectural paradigm called MARIO, standing for (Making Assets for Rendering I/O Optimized).
In a nutshell, we move bandwidth and space-consuming model and texture data from RAM and disc media, where it is time-consuming to load, to super-fast ROM, contained within the GPU itself. Having this data in silicon will dramatically speed up the rendering process and hence the user experience overall.
You may ask, how do we modify these models and textures? Of course, that is not possible, but we've done great research, and have found that for most of our games, the same models and textures are always being used anyhow, so it makes sense to put those in ROM.
Specifically, we're embedding data for Mario, Luigi, Donkey Kong, the Princess, and Link into ROM. For 99% of our anticipated future games, this will cause a dramatic speedup in performance, and will provide a great incentive for game developers to license the use of our assets in their games, instead of using their own proprietary non-Nintendo characters in order to make their 3-D rendering pipeline as efficent as possible.
We at Nintendo look forward to the quantum leap in graphics performance this new architectural vision will surely bring on and are quite excited as you can see!
-- Samir Gupta, Ph. D. Head, New Technology Research Group, Nintendo Co. Ltd., Kyoto, Japan.
Longhorn.
U rawk d00d! You went from the head of Sega R&D to Nintendo's R&D, quite a jump!
No really, I was there.
Many Times the Free Software movement has been critiziced for doing that, but in that case we had good reasons 1) Ethical 'Improve' 2) Thecnical Improve. But, in this case, m$ is just developing something that allready exist, just for commercial reasons. And, in this case, everyone seems to agree with that, they even can accept the missfeatures of beta realeses that are being sold (while the same people seems to not accept beta releases that are out there to download for free). It seems that if software is propietary, and with a big company behind it, people accepts aggresive changes, backward incompatibility, hardware issues, failing drivers, beta features puted on so called 'realeses' that are actually being sold. But, they can't take that from Free Software, they try to take down HURD because they say there is allready a Free Unix Kernel, they talk against free software by naming those 'unstable, unsupported' beta features. But when beta code is hacked into a propietary products and sold away, they call them 'New Advanced Features'.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
What, you mean it's not going to be called DirectXX?
It would certainly get someone's attention...
The Penguin Producer
Are you guys retarded?
/me blinks
Why is this modded up to insightful, instead of funny?
Those markets are too insignificant to bother with.
Xbox Next, if it's not just a codename, is already triple X. Whether this is XXX in the Vin Diesel style or XXX in the high-nudity low-artistry style is still in the proverbial air.
I guess we all know what the Next version of Windows is going to be called! :)
As I understand it, the next version of Windows is code-named Donghorn.
-kgj
-kgj
It's just sad to see how far down Slashdot has
sunk these days.
In a nutshell, we move bandwidth and space-consuming model and texture data from RAM and disc media, where it is time-consuming to load, to super-fast ROM, contained within the GPU itself.
The Intellivision console actually tried storing 3/4 of its textures in ROM, which is why so many of the games for InTV look the same. I originally thought this was true of the NES as well, what with the uppercase Latin font being identical across so many early NES games and with early Game Boy games having a different font altogether, but the first time I went ROM hacking, I realized this wasn't true.
Speaking of ROM hacking, if you really did work at Nintendo, I'd be sued by now.
Specifically, we're embedding data for Mario, Luigi, Donkey Kong, the Princess, and Link into ROM.
Wouldn't the Bowser model be more detailed than the Mario model, requiring more of a load time and becoming more of a candidate for on-console caching?
Another objection: ROM is slow and expensive; hard disk drives, as used in the Xbox console, are much cheaper and still faster than typical DVD-ROM. Couldn't the game keep the models on the disc and then cache them on the HD, possibly sharing models between a pre-installed Smash Bros. 3 and many of Nintendo's other flagship titles?
When it comes to graphics, what I want is exactly "Whiz-bang" features.
Graphics whore since 1983 and proud of it!
Will code a sig generator for food
Sorry dude, but you got trolled. Someone used this on Fark yesterday.
Buy Steampunk Clothing Online!
obsession with X's will finally bring you to triple X. What an operating system that would be!
It's called the 'internet'
If graphics were all about eyecandy, maybe you'd have a ...oh. RainbooOOOw.
Buy Steampunk Clothing Online!
If you're into graphics, then portability, hardware support, and scalability ARE the "whiz-bang" features.
Now, if it's just gaming you're into...
Maybe i'm not the only one, but i've done a little 3D animation in my life. From my experiences, i have found that DirectX is far slower than OpenGL or Glide. When it comes to rendering, or simply editing in 3D, OpenGL is far faster then DirectX (I use an Radeon 9700Pro and a 3Dlabs Wildcat VP760). Also, when playing games that support OpenGL, they tend to run much smoother and faster with OpenGL.
Hi there
The screen will automatically sharpen to compensate for the drunken blurring from drinking excessive quantities of Australian Lager.
Australians couldn't give a Windows 4X for anything else
DirectX runs at 0fps on my Linux machine. I don't see how anything else could be slower.
Also if Neverwinter Nights isn't a "real" game, I'm the king of France.
Karma: It's all a bunch of tree-huggin' hippy crap!
'Shader' is a DirectX fluff term for what a real API would call a 'program'. Maybe if they'd called them 'pixel programs' instead of 'pixel shaders', people would more easily understand what they do.
Um, it's called parody. Or satire, if you prefer.
I've had this sig for three days.
That has nothing to do with DirectX.
Deus Ex 2 specifically uses hardware Pixel Shaders in its engine. If your card doesn't use them, it won't run, because Deus Ex 2 was programmed that way. The GeForce MX cards are not supported.
What people mean by backwards compatibility in DirectX is that DirectX 9 doesn't break compability with games that use earlier versions of DirectX. For instance, I'm typing this on a laptop that has a Mobility Radeon 7500, and I have DirectX 9 installed and can still play Black & White or Deus Ex 1. They each use different earlier versions of DirectX.
DirectX 9 can't make your card do something it doesn't have the hardware support for. Backwards compability with earlier cards just means it will still also do DirectX 8's hardware features, DirectX 7's, and so on. It's inclusive with each previous version's features. Each new DirectX version just adds new hardware features and capabilities to the 3D interface that newer cards can take advantage of.
Deus Ex 2 should have had an option to turn off the Pixel Shader bump-mapping, and then your card would have ran it, since it doesn't do Pixel Shaders 1.1.
"Sufferin' succotash."
The article's really long, and somewhat technical. Here's the layman highlights for anyone who just wants to know "Ok what should I care about?"
.plan update which you can find here: http://www.bluesnews.com/cgi-bin/finger.pl?id=1&ti me=20000308010919
1. The big change is all memory goes virtual. What this means is that you don't need to load an entire texture to render a subset of it's pixels. This is a VERY good thing considering on most textures you're only using a low level mipmap anyway. Thus, texture memory on the card becomes more like a gigantic L2 or L3 cache that can be efficiently used. Also you can have massive texture spaces without having things go all slow over AGP. 3Dlabs' Wildcat already does this. This was originally mentioned by Carmack in the 3/27/2000
In addition, geometry is stored virtual as well, as are shaders, which can be loaded into the processor in pages, instead of being limited to a small block of instructions that have to fit entirely into the GPU registers. The registers now work more like an L1 cache, and shader programs can be effectively unlimited size. This means lots of neat special effects will be possible.
2. High ordered surfaces (curves) are getting mandated. No more n-patches vs truform, it's going to use standard curve systems like Beizer splines.
3. Fur rendering and shadow volumes are going into hardware as part of a new "tesselation processor"
4. You can have multiple instances of meshes. This means you can take one model, run a few vertex programs on it, and store each result seperately. Saves alot of time later.
5. Integer instruction set. This is so you don't have to deal with floating point data when you don't need to. There are some times you want simpler data for use in a shader program and having to pretend everything's a floating point texture isn't convenient.
6. Frame buffer current pixel value reads. This has been a developer request for a long time. It's not mandatory in the spec, but it can be used for all sorts of stuff. Basicly the GPU can read the current value in the framebuffer into the pixel pipeline without needing to maintain a second copy. This will both save alot of memory and allow you to do things such as light accumulation more efficiently.
Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!
"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."
But, but...I wouldn't be able to boost Microsoft's marketshare, and cut into OpenGL's if I told the truth.
Waaa, I want Microsoft to win so bad, I'll come onto a site full of knowledgable geeks, and FUD my nearest competitor OpenGL. waaa.*
*The perceding was brought to you by Captian Obvious.
There doesn't appear to be a single thing in there to address physics. This means that I'm still going to get monsters in the wall, explosions that go through floors and clothing passing through players, it's just going to look nicer.
Ecerquest was Windows only for a LOOOONG time. It was a Windows/DirectX app from inception. Only long after it had been out (like 3 years) was it ported to other platforms, and that was after it's prime.
There is a real difference between somethign that was developed as a Windows game, then later because of its success, had effort spent on it to make it work on another platform, and a game that was designed using open standards as to run on more than one platform from the beginning.
the article only dwells on Direct 3D which is far from being an article on Direct X. There are other bits to Direct X which I'd like to hear early news on.
RTFA.
Why it is no company likes to call its software version 10?
It's not DirectX 10, its DirectX Next
It's not OS 10, its OS X
It's not Redhat 10, its Fedora
Do companies think that people won't use anything labeled 10? Or, maybe they just assume the average consumer can't count the high.
Well, I'd like to see how DirectX 10 does.
I think I think, therefore I think I am.
One thing that many people might want to consider when comparing DirectX and OpenGL is that DirectX is a suite, and GL an interface to the 3d extensions (and 2d) of your video card.
However, with that in mind, is there an equivilent suite that incorporates GL? 3D graphics are nice, but I do remember thinking nice things about DirectMusic (situation-themable audio events) and DirectSound. Is there anything we can use to compare to directX as a whole?
Being that I'm currently working on learning/developing using C++/GL in linux, it would be nice if anyone could point out any extensions aside from just graphics (which, while they may be a large portion of a game/multimedia-app, are not always all of 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.
Bad analogy, since MMX is much more low-level. If you run MMX-code on a non-MMX-CPU it will not somehow be emulated but probably just crash you machine. The coder has to make sure that he has different code-paths in this case, and there is no library that takes care of that.
Don't DirectX games absolutely blow chunks when playing across untrusted networks? I mean, they always have in my experience, but that's limited to the Civilization series of strategy games.
Configuring a firewall to pass the ridiculous number of ports required is a pain in the ass (I actually wrote a script to do it because it's too tedious otherwise) and you still can't have multiple players inside and outside if you're NATted to a single outside address. Well, OK, you can sort of do it if you are willing to settle for huge performance hits and major lack of function.
I suspect directX has evolved into a scam to sell uPnP firewall technology, which is out of the question for anyone who actually needs a real firewall.
This is really sweet. There's any number of times I've wanted to store one shader in the light and one on the mesh and just combine them. it looks like this would allow you to run through once with the light shader and then run through on a second pass with your stored mesh on the specific mesh shader. Unless I'm misinterpreting (if I am ... someone please make this happen... it'd make writing the shaders *so* much easier)
6. Frame buffer current pixel value reads. This has been a developer request for a long time. It's not mandatory in the spec, but it can be used for all sorts of stuff. Basicly the GPU can read the current value in the framebuffer into the pixel pipeline without needing to maintain a second copy. This will both save alot of memory and allow you to do things such as light accumulation more efficiently.
mixmode is dead!!! long live framebuffer reads.
People who quote themselves bug the crap out of me -- Me.
There's no such thing as a free port. Even if you're using largely the same APIs.
I have 94 freaks. :P
I hate liberals. If you are a liberal, do not reply.