In preparing for the arrival of LRB-1 hardware, I have been updating my personal testbed to D3D10.
Yes, I had been stuck in a D3D9 rut for a while, just like a lot of the rest of the industry. :-)
My personal testbed is based on a maze-generation and solving algorithm, the Kruskal algorithm. A good page to describe maze algorithms in general is here. From this you should understand that a Kruskal maze is a "perfect" maze or a minimal spanning tree over a set of cells in comp-sci speak. I use the "wall-follower" solving strategy.
I decided to use a maze as a testbed for several reasons. First, it lets me easily generate "level geometry". Second, I can use different creation and rendering strategies for the level geometry. to use different Draw APIs, different Draw API frequencies, and advanced features like Instancing and TextureArrays. Third, inside each "cell" or "room" is a perfect candidate to render some special effect like a particle system, an animated object, a reflection system, a shadow system, or something like that. Fourth, I can set up and manage different camera/views. Fifth, the viewpoint inside the maze that tracks the solver is perfect for rendering an animated character.
That is a lot of leverage out of what is a relatively simple algorithm, which is why I picked it and have been using it since D3D6 to keep my skillz current.
Now that I have some simple D3D10 code working, I want to write this up as both a service to other developers and a way to solidify my learnings in my own head. I will use the same style I had in the Driving DirectX articles, which you can see from this article on Flipcode which was essentially the last article in Driving DirectX from me.
I am going to leverage the new DX SDK framework DXUT, which enables writing a single app that will work on D3D9 and D3D10. Some features will be slightly different, due to the fact that the D3D10 SDK does not support .x files well, but other than that the functionality will be the same.
I see 7 articles so far:
1) Explanation of DXUT and what it gives you
2) Basic sample, renders only a frame rate
3) Rendering a "skybox" to place your level "inside" something and give the feel of being in a world.
4) Generating the maze geometry and rendering it
5) Using multiple cameras
6) Solving the maze
7) Rendering a skinned character at the location of the "inside the maze" camera
Each article will cover both the D3D9 and D3D10 implementation. All rendering uses D3D Effects ( .fx files ) and HLSL. SM 2.0 for D3D9 and SM 4.0 for D3D10. If any single article gets too large I will consider splitting the D3D9 and D3D10 pieces into a "2-fer".
Once we get that far, I will see what else I have time for. Possibilities include Instancing and TextureArrays for the level geometry and special effects in a randomly selected subset of the rooms.
The other "big" thing I intend to do is port this to LRB-1 and generate the same series of 7 articles on LRB-1. Hopefully that will also be of some interest?
I am currently working on the D3D9 skinned character in the code for article 7, so the work is well along. Once I finish that code, then the article production beings. So we'll see how fast I can finish the D3D9 skinning code and then pump the first two articles out, and that will give us an idea of what sort of pace you can expect from me. I'd guestimate 2 weeks for the 1st article.
And by the time that is done, the time to start talking LRB-1 in detail should be closer.
And Happy Thanksgiving!
3D Graphics Card Blog
- The guys at Guru 3D have previewed the new Geforce GTX 295! [image: image] No matter what game you'll play with the GeForce GTX 295, you'll play it at ...
5 months ago
Posts
8 comments:
That sounds really good ! I guess all those articles will be written in c++.
I guess that the port on LRB-1 will be in c++ too.
What will happen concerning managed code like xna ?
As far i know, Xna is just calling the DirectX API and wrapping it in a elegant manner.
Can we expect a good way to use managed code on LRB-1 ? Maybe a .NET API ? It would be so great !
Your new blog is really interesting Phil.
Thanks you for all those interesting informations and Happy Thanksgiving too !
Fooogooo thanks for your comments.
Yes, my articles will be C++, Visual Studio 2008 projects.
Please do not get me started on the platform strategy disaster that is .NET support for DirectX from Microsoft.
Right now all LRB-1 plans are C/C++ but if I hear of .NET on LRB at all on the device side I will update.
"Please do not get me started on the platform strategy disaster that is .NET support for DirectX from Microsoft."
LOL!!!
I like this blog Phil
Keep it coming~!
I hope you will expose your opinion about that point :-)
I am curious to understand your point of view, Phil.
I hope we will soon read your articles.
Foogoo,
It is pretty simple really.
.NET is a Windows platform play.
DirectX is a low-level Windows platform technology and an enabler for all kinds of functionality and developers.
It follows then, that as a 1st principle, Windows platform strategy requires DirectX exposure on .NET.
Not having DirectX exposure on .NET *is* a major Windows platform gap. period. end of line.
Managed DX 1.0 filled this gap for the .NET team back in the day. But time and technology has moved on.
What framework version are we on now? 3.5?
What DirectX version are we on now? 11 is in beta?
So having only a managed wrapper for DX9on Framework 1.1 is a sad exhibit of Windows platform support.
I am a bit surprised the .NET team havent called this out and pushed the DX team that own the DX API or the Entertainment and Devices team that now own the DX SDK to fill the gap on Windows.
Hoever, they have their own gaps over in DevDiv, some of which are suprising in their own right - one of which I filled in my time there, so perhaps that consumes their attention.
In those terms, XNA is a distraction, a bright shiny object to divert attention away from the gap in Windows platform support.
But XNA *is* political inside MS in that it has *juice* and no one wants to get in front of a force like that and put forth the argument it doesnt really help Windows.
Witness, the pullback of the Managed DX 2.0 beta, which was designed to get modern DirectX exposure for .NET, eg on Framework 2.0 on Windows.
The best one can say for XNA is that it helps XBox360. It is hard to not see it as yet another example of the decay of PC gaming support from MS since it exposes nothing on Vista/DX10 and instead "levels" development to XBox360/DX9 functionality. This helps Windows gaming how?
This is similar to the sad story that is DirectShow/Direct3D integration, but thats another gruntle for another day.
Phil
PS. As far as articles the code is now basically done, I just need to start writing them. Another week or so.
Thank you Phil ;-)
I can't say anything else ... you 've just sum up the situation and clean the fog i had in front of me ...
"Not having DirectX exposure on .NET *is* a major Windows platform gap. period. end of line."
I have never thought this way ... but that so true and simple : Why DX is not exposed in .NET like any other win api ?
I really like Xna, but you're right again ... it is not what we can expect from Msft as a platform provider.
It offers some great choices, and it is really easy to learn. But now that I am comfortable with Xna ... i feel exactly the same as you : What about Dx 10 / 11 ? How Xna helps Windows as a gaming platform ?
It is a great toy for developers, but not what you can expect as a GAME developer. Today, i write some piece of code with xna because i have fun writing a game for my own use ( oh my, dealing with SRTM data is really a hard piece of code) , but i can't imagine writing a game not using Dx 10 / 11 ... Dx 9 is far from deprecated, but it is now a 'previous version'.
Default should be Dx10 and Xna should offer that. My point of view.
So bad that xna is related to Xbox360 ... That really slow down the evolution of Xna.
But hey ! Here we will talk about Intel bits and piece of silicon ... not Msft gap and strategy ! ( hum ... i think we will do it again ... )
Oh please Phil ... do not talk about DirectShow ... please ! I spend so many month writing filters ...
I had fun when i read your FS blog, and now i really appreciate this one because you always take the time to answer and discuss with your readers ;-)
Ok, thanks to Phil pointing this comment thread out to me, I feel compelled to speak, having been in the center of the mess (and no longer being employed at Microsoft), I feel at ease pointing fingers :-)
Here's the really short version:
There was a sub-team on the DirectX team of one person. His name was Tom Miller. He wrote Managed DirectX.
Managed DirectX became popular, but nobody on the DX team really knew what to do, since they were very focused on native DX game developers and only "hobbyists" were using MDX. However, it was becoming popular with the managed development crowd (including a couple of major corporations).
Because there was no real revenue opportunity with MDX, the team remained a one-man team, until Tom Miller left to join the Xbox org to do this new XNA thing.
A few months later, the DX teams and the Xbox team had a lopsided, forced-merger of some parts, which left the DX team even more understaffed and, to be honest, disinterested in MDX, particularly when the XNA team was trying to publish a new managed API for gaming.
The biggest problem was that they didn't make it clear to customers that MDX was going away. That impacted people internally as well -- the decision to abandon MDX deeply impacted the Playtable/Surface team. Some of them will still throw office furniture if you mention Managed DirectX within earshot :-)
Meanwhile, on the XNA side, they were (and still are) busy adhering to their #1 goal: Make the Xbox profitable. They have NO business interest in doing anything with XNA that would marginalize the Xbox (like, say, creating a version of XNA that works with DX10/11). Remember, the XNA team works for Robbie Bach, and he has ZERO interest in the success of Windows on a business objective level.
This will likely get MUCH more complicated with Win7, because the Windows team is under a stronger mandate to expose Win APIs (including D3D/D2D) to managed code. This means that there WILL be an eventual schism between XNA and the DirectX side when it comes to managed code development. However, there are people on the XNA team that want to make sure that impact is negligible, if not transparent. It remains to be seen if that will come true.
In the end, people were burned by thinking of Microsoft as "one Microsoft" instead of looking at the organizations and their business motivations. But Microsoft should have done a more timely job of being CRYSTAL CLEAR about the viability of MDX as an API (as in, MDX 2.0 beta should never have been released).
The ultimate guidance I have (and will) give people is this: If you care about keeping up with DirectX, don't use XNA. If you care about making inexpensive games for the Xbox 360, use XNA.
Yes, Dave. I know about the history of MDX. I was the PM before I left MS the 1st time.
That doesnt change the fact that what has happened is bad platform strategy. On the part of both the DX team in Windows and the XNA team in XBox.
You are right, though, in that the events that have transpired make it clear that the XNA team only cares about making XBox profitable and couldn't give a fig for Windows and PC gaming, we can agree there.
As I said, that is good for PC gaming how? We both know it isn't.