Skip to main content
GameDev.net gamedev.net
🔒 Locked

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

Started by LetsKillDave Mar 15, 2006 at 1:33 AM 46 replies 13k views
Original Post
LetsKillDave
LetsKillDave
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? :-)
boontje
boontje
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!
ramy
ramy
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).
LetsKillDave
LetsKillDave
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? :-)
jollyjeffers
jollyjeffers
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 |
Demirug
Demirug
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.
jollyjeffers
jollyjeffers
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 |
Demirug
Demirug
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/
jollyjeffers
jollyjeffers
Ah, ok - makes a bit more sense [smile]

Interesting link as well, I've got some of their work in a book from a couple of years ago - didn't know there was material online as well.

Cheers,
Jack
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
Armadon
Armadon
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.
Promit
Promit
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.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
sirob
sirob
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.
Sirob Yes.» - status: Work-O-Rama.
Moe
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...
jollyjeffers
jollyjeffers
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
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
ramy
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).
jollyjeffers
jollyjeffers
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
<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ |
thezbuffer
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

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

ZMan
jogshy
jogshy
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....
circlesoft
circlesoft
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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.