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

Started by
46 comments, last by jollyjeffers 18 years ago
http://www.inkblog.com/2006/03/15/Managed+DirectX+And+XNA.aspx More details in a few days, but I'd definitely like to hear your thoughts/feedback.... [Edited by - jollyjeffers on March 20, 2006 11:44:21 AM]
David "LetsKillDave" WellerNVIDIA Developer Programs ManagerPersonal blog http://letskilldave.comPersonal Twitterfeed: letskilldaveNVIDIA Developer Announcements Twitterfeed: nvidiadeveloper (clever name, eh? :-)
Advertisement
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.
Slurcko Durcko Duck!
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).
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.
David "LetsKillDave" WellerNVIDIA Developer Programs ManagerPersonal blog http://letskilldave.comPersonal Twitterfeed: letskilldaveNVIDIA Developer Announcements Twitterfeed: nvidiadeveloper (clever name, eh? :-)
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?
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. )
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

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

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.
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

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

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/

This topic is closed to new replies.

Advertisement