Sign in to follow this  
LetsKillDave

A little more about XNA... (*Updated for the GDC'06 announcement on "XNA Framework"*)

Recommended Posts

Quote:
But I will also second Tom's request: Please let me know how you're using Managed DirectX, especially if it's for a commercial product. One of our biggest challenges is reaching the broad community and understanding how you're using our APIs, and I admit it's particularly difficult for Managed DirectX. We continue to be surprised about what companies are using it and how.


Quite simple actually: we use it ONLY for prototyping and internal tools. For anything else which is going to be a high quality product which we want to ship we do not use managed DirectX. Purely based on performance, which is missing in a managed enviroment.

Share this post


Link to post
Share on other sites
Thats looks like something interesting to look out for. So I take it that XBox 360 will support .NET Framework? Since its dev kits will be able to run CLR apps. I go with boontje on that one. We also used Managed DiectX for internal tools. Then again we had to switch to native DirectX for console easy compatiblity in the future, since consoles won't be supporting .NET Frameworks (or atleast everything arround us was telling us so).

Share this post


Link to post
Share on other sites
Quote:
Original post by boontje
Quite simple actually: we use it ONLY for prototyping and internal tools. For anything else which is going to be a high quality product which we want to ship we do not use managed DirectX. Purely based on performance, which is missing in a managed enviroment.


Understood. Just like in the days of Assembler vs C, or C vs C++, each approach has tradeoffs between performance and productivity. We completely understand that, in order to achieve maximum performance, you will want to work with native (unmanaged) code. I imagine, as the years progress, that we will see more DX applications running in managed code.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Will Microsoft continue support for DirectX applications developed in C/C++ ? Native that is? Or will we slowly go over to managed-only DirectX applications? Whats Microsofts vision about this?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
Will Microsoft continue support for DirectX applications developed in C/C++ ? Native that is? Or will we slowly go over to managed-only DirectX applications? Whats Microsofts vision about this?


You should have no concern about the continued support of unmanaged directx development. The vision about XNA will hopefully become a little more clear during GDC week.

Paul Bleisch [MS]

(still too lazy to log in. )

Share this post


Link to post
Share on other sites
I'll sticky this thread for a bit so it can get some attention [smile]

Quote:
Original post by Anonymous Poster
Will Microsoft continue support for DirectX applications developed in C/C++ ? Native that is? Or will we slowly go over to managed-only DirectX applications? Whats Microsofts vision about this?
I would be extremely surprised if support for C/C++ programming disappears anytime soon. Even if people don't see it as a "looking forwards" technology/language, there's still a huge amount of existing C/C++ code (libraries, engines, examples..) and, at least in games, a substantial proportion of the workforce trained in using it.


I'm just hoping that GDNet covers this cool new stuff at GDC [grin]

Cheers,
Jack

Share this post


Link to post
Share on other sites
We use managed DirectX inside our render command analyzer tool. It is a little bit like pix but with other features.


Old screenshot the UI looks different now.

Additional we are working on a game engine based on .Net with different backends (MDX 1, a managed D3D10 layer, Mobile D3D, maybe a managed OpenGL layer). One nice part is our MSIL to High Level Shader Language converter in the Toolset.

Share this post


Link to post
Share on other sites
My general comments on the use of MDX:

I don't personally use it myself, but our project would most definitely have benefitted from being entirely MDX. Performance nor flashy graphical features aren't so important for that project - but rapid/easy development would have made things so much easier. By the time .Net and MDX became a viable option we were well down the path of using other languages.

The only question mark over using it next time is the cross-platform viability. Unless I've missed something (e.g. this CLR-on-a-360 thing) choosing C#/VB/MDX from the outset fundamentally limits us to Microsoft platforms. Bit of a bugger when Sony holds the licence for F1 [lol]

Quote:
Original post by Demirug
One nice part is our MSIL to High Level Shader Language converter in the Toolset.
So, if I understand you correctly - you can convert (presumably not everything will work?) the MSIL generated from a .NET language into HLSL, which can then be compiled and used via D3DX as expected?

Sounds quite clever, but not to sound negative - why? [smile]

Is there much need/use for generating shaders from MSIL?

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Quote:
Original post by Demirug
One nice part is our MSIL to High Level Shader Language converter in the Toolset.
So, if I understand you correctly - you can convert (presumably not everything will work?) the MSIL generated from a .NET language into HLSL, which can then be compiled and used via D3DX as expected?

Sounds quite clever, but not to sound negative - why? [smile]

Is there much need/use for generating shaders from MSIL?

Cheers,
Jack


We used MSIL because it was easy to parse and Graphics API independent. We have other representation (like Maya Shadertrees) too. Overall the whole thing is a little bit more complex. We have classes for geometry, lights and surfaces that are combined together to a big “Shadertree”. In a next step this tree is optimized and split in multiple parts (CPU, vertex, pixel) depending on the data sources. The back ends than generate the shadercode or better say the whole “effect” (this is an xml file with shadercode an other settings). We had even play around with automatic multipass generation and the results were not that bad.

This inspired it: http://graphics.stanford.edu/projects/shading/

Share this post


Link to post
Share on other sites
I truly believe that it's a step in the right direction for development. It's been a awesome run so far and the adoption of MDX in the community has been great. Myself and Rim are just excited to see this technology continuing.

Share this post


Link to post
Share on other sites
I'm quite excited about MDX on Xbox (although Tom basically told me by accident that day [lol]). Really I'm kind of surprised it didn't happen earlier, but I guess these things take time.

I've moved completely over to managed code, myself. I have the skill necessary to squeeze every last cycle out of unmanaged code, but I simply don't have the time it takes to do all of that work. I'm still a hobbyist-student, so quick development is a real boon.

Oh, and David -- I got the offer and accepted it. I'll be working with the Table guys starting in June.

Share this post


Link to post
Share on other sites
I havn't been doing much CPU intensive work with MDX, but from the work I've done, I've actually not seen any notable performance loss. I know this doesn't apply to any application, but I managed to port my terrain renderer from native code to managed code, and it still ran at exactly the same speed.

Porting it then allowed me to faster add in optimizations, so at it's current stage, the MDX (MDX2.0, actually) app is running faster than the older native application. I don't feel I'd have any trouble expanding this application further, and .NET certainly won't be limiting my progress, only speeding it up.

Two thumbs up for MDX 2.0 :), even if it is still beta.

Share this post


Link to post
Share on other sites
Okay, maybe this is the wrong thread to ask this in, but can you only use MDX with C#/VB.NET? I am still a bit unclear on the whole managed vs. unmanaged DX thing...

Share this post


Link to post
Share on other sites
Quote:
Original post by Moe
Okay, maybe this is the wrong thread to ask this in, but can you only use MDX with C#/VB.NET? I am still a bit unclear on the whole managed vs. unmanaged DX thing...
Yeah, probably best to start this in a new thread if you want a proper discussion, but as a quick answer... You should be able to use MDX via any .Net language. The two other common ones should be J# and (Managed) C++. There are a whole load of other .NET languages, but I can't remember the names of them now [smile]

Jack

Share this post


Link to post
Share on other sites
Ok, so I take it from "Promit" reply that there will be MDX on XBox 360. I really wish somebody from XBox team or DirectX people said that earlier (althought I was replied to as no there won't be).

Share this post


Link to post
Share on other sites
Quote:
Original post by ramy
Ok, so I take it from "Promit" reply that there will be MDX on XBox 360. I really wish somebody from XBox team or DirectX people said that earlier (althought I was replied to as no there won't be).
To my knowledge, it's still not an official fact. Seems to have been hinted at by David's blog and Promit's post, but it seems it might be unveiled at GDC next week...

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
To my knowledge, it's still not an official fact. Seems to have been hinted at by David's blog and Promit's post, but it seems it might be unveiled at GDC next week...
Jack

All that is currently 'official' is
1. the compact framework team have CLR running on a 360 Dev Kit
2. Tom Miller now works in the XNA team, but is still something to do with Managed DirectX
3. There will be a demo at GDC of managed code running on a 360 Dev Kit

http://www.thezbuffer.com/articles/369.aspx

Share this post


Link to post
Share on other sites
Well, I LOVE .NET ( specially c# and mc++ ) and managed directx. I think .NET on the xbox 360 is a great thing. My dreams come true... Vista with .NET... xbox 360 with .NET... Mac/Linux with .NET (mono)... GOOOOOD!

I am working in a 3d engine... I use C/C++ for the core ( due to portability... sorry PS3/GameCube can't use .NET)... I provide a managed C++ wrapper ( so the people could use c#, vb.net, mc++ or j# with it ). The engine editor and tools are made in c#.

Btw, I am not sure if you know the Reality Engine ( http://artificialstudios.com ) but it uses .NET plenty and is wonderful....

Share this post


Link to post
Share on other sites
Quote:
Original post by thezbuffer
Quote:
Original post by jollyjeffers
To my knowledge, it's still not an official fact. Seems to have been hinted at by David's blog and Promit's post, but it seems it might be unveiled at GDC next week...
Jack

All that is currently 'official' is
1. the compact framework team have CLR running on a 360 Dev Kit
2. Tom Miller now works in the XNA team, but is still something to do with Managed DirectX
3. There will be a demo at GDC of managed code running on a 360 Dev Kit

Very nice [grin]. I am looking foward to that. However, from a middleware dev's perspective, we still probably aren't going to spends hundreds (possibly thousands) of man-hours making a managed port until:

(a) We get lots of customers asking for it
(b) Enhanced cross-platform support. Which it looks like we are headed there - except for platforms outside of MS control (like Sony, Nintendo, ect).

Quote:
Btw, I am not sure if you know the Reality Engine ( http://artificialstudios.com ) but it uses .NET plenty and is wonderful....

Well it certainly uses .NET. Scratch the wonderful part though.

Share this post


Link to post
Share on other sites
Quote:
MDX on XBox 360


This would be the singlemost important thing to happen to MDX in my opinion. By making it available on the XBox 360, Microsoft opens up the world of console gaming to MDX developers, which

1) would be a great market to be able to operate on, especially with Live Arcade

2) underlines the professional value of MDX as well as Microsoft's commitment to its future.


Quote:
Understood. Just like in the days of Assembler vs C, or C vs C++, each approach has tradeoffs between performance and productivity. We completely understand that, in order to achieve maximum performance, you will want to work with native (unmanaged) code. I imagine, as the years progress, that we will see more DX applications running in managed code.


I think there are other factors here than performance vs productivity. MDX deployment has been a bit of a hassle, as well as a clear view of the future of the API (more info on that would still be welcome [wink]) and of course the relative newness of it. I've not been on board with the GameDev community for very long, but I'd say that MDX has only been actively marketed by MS since about Summer 2005 and given that, the speed of adoptation looks very promising.

But please, pretty please stop throwing the MDX (or even CLR) performance issue at us. Of course I'm biased, but if there's anything I've learned in over 7 years of commercial coding, that would be that it is entirely possible to write non-performant code in any language on any platform. Especially on the subject of realtime (3D) programming, where single misplaced function call can kill performance, I have serious doubts that the choice of platform should have that much impact.

There, that's the first and only time I'm gonna speak up against the speed misconceptions on MDX. I have no further desire to continue this discussion in public and drawing this thread offtopic, since I think a platform choice is really a matter of personal preference, especially when they're feature-equivalent like DX and MDX. If anyone wants to continue this discussion though, feel free to send me a PM.

Quote:
However, from a middleware dev's perspective, we still probably aren't going to spends hundreds (possibly thousands) of man-hours making a managed port


I can see that this probably isn't feasible, but DirectX middleware also didn't appear overnight. I feel that MDX is currently aquiring enough momentum to actually make a break-through into professional gaming end-products (especially with the prospect of 360 deployment). Once it has actually become a fully mature platform in this regard, I have no doubt that more MDX middleware will start emerging.

On the other hand, the excellent CLR facilities for working with native code should make it relatively easy to write a managed wrapper for your middleware so it can be used in a managed (MDX) environment. This will allow you to maintain a single native codebase, while giving you deployment opportunities on both platforms. That approach seems to work for plenty of other middleware.

Quote:
Please let me know how you're using Managed DirectX, especially if it's for a commercial product.


Well, here are some things we've used it for up until now:

- A little game for the "Seeing Double" competition
- Another (unfortunately limited) game for the 4e4 competition
- A volume texture tool

We're currently planning to use MDX for doing some fancy visualizations of information structures from a commercial package of ours, which will be used for presentations, front-office desk work and public data enquiries.

Share this post


Link to post
Share on other sites
Quote:
Original post by remigius
On the other hand, the excellent CLR facilities for working with native code should make it relatively easy to write a managed wrapper for your middleware so it can be used in a managed (MDX) environment. This will allow you to maintain a single native codebase, while giving you deployment opportunities on both platforms. That approach seems to work for plenty of other middleware.

I suppose that if you wait until the end of the development cycle, that would work. This seems to work for the D3D team rather well - they finish the core unmanaged API, and then begin work on the managed extensions. This way, they aren't constantly refactoring their wrappers.

So, I guess we'll see. If people start asking for it, it could happen.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this