Jump to content
  • Advertisement
Sign in to follow this  
LetsKillDave

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

This topic is 4489 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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.

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!