Taking My Engine Back From C#/MDX 9 to C++/DX 9...
Author
Well, I just started writing an engine using C# and MDX. I haven't gone very far, just initialization of DX, etc. And I've decided to switch back to pure C++ and DirectX. Is this recommended?
I'm comfortable with both C++ and C#, and with DirectX in both. I've heard, and noticed myself, that pure C++/DirectX is faster than C#/MDX. And I'm placing my engine in a library (DLL). Would it be recommended to use C++ instead, if I'm kind of looking a little more for speed, and using a library?
I know it's a kind of stupid question. But I wasn't sure exactly what would be the best route to go. I figured C++, myself, but is that true? Speed is one thing I'm looking for. But I actually find it a little bit cleaner to use C++ as well. C# seems like the language I'll use when writing somewhat complex Windows (WinForms) applications, database-driven apps., etc.
And when I use the engine to make a game, it'll be bad enough if the user/friend/etc. doesn't have DirectX 9. But they'd also have to have the .NET Framework 2.0 if I use MDX. So what are your thoughts.
And if you have anymore information on what advantages C++/DX has over C#/MDX I'd love to hear them. I'd like to know a little more about the differences. And I don't really want opinions. I'm looking for facts. =)
Thanks in advance,
Matt U.
Speedwise, I think the MS claims MDX is about 95% of unmanaged DirectX. You may have a lot of other functionality in your engine though, that would benefit more by the manual optimizations you can do with C++ but not with .NET. I wouldn't consider that kind of speed difference significant when choosing technologies.
Distribution of .NET and, even worse, MDX, is where it hurts. Hopefully this will get better with XNA, but currently it's a real show stopper.
I myself don't have a tight schedule, I distribute my professional projects on CD-ROM, and I don't care if I'm 10% slower than max framerate. My choice is definitely MDX.
Distribution of .NET and, even worse, MDX, is where it hurts. Hopefully this will get better with XNA, but currently it's a real show stopper.
I myself don't have a tight schedule, I distribute my professional projects on CD-ROM, and I don't care if I'm 10% slower than max framerate. My choice is definitely MDX.
The native versus managed DirectX argument isn't really a substantial one - I believe the target was that blow-for-blow MDX should be within 97% of the native equivalent. I don't know if they achieved that exact target, but I'm not aware of any conclusive evidence that suggests managed is that much slower than native.
However, thats just regarding individual function calls - jumping the API boundary if you like. It doesn't factor in any other "pure language" differences - accessing and manipulating data structures, executing algorithms etc...
Although, in my experience of comparing languages its almost always a moot point - you can write crap/slow code in any language [smile]
My advice would be to go with whatever you're comfortable with and what suits your needs. I dont believe there is a strong enough reason to pick either language/method based purely on performance. Although, if you're a better C++ programmer than you are a C# programmer chances are you'll write cleaner, faster and generally more efficient code...
Distribution problems can seem daunting but they can all be solved with a little effort. Again, I wouldn't let this push you away from a .NET route...
FWIW, I would personally still choose DX9/C++ hands-down over MDX because of familiarity. I am however giving serious thought to moving any future tool/editor/prototype development to C#/.NET.
hth
Jack
However, thats just regarding individual function calls - jumping the API boundary if you like. It doesn't factor in any other "pure language" differences - accessing and manipulating data structures, executing algorithms etc...
Although, in my experience of comparing languages its almost always a moot point - you can write crap/slow code in any language [smile]
My advice would be to go with whatever you're comfortable with and what suits your needs. I dont believe there is a strong enough reason to pick either language/method based purely on performance. Although, if you're a better C++ programmer than you are a C# programmer chances are you'll write cleaner, faster and generally more efficient code...
Quote:Distribution of .NET and, even worse, MDX, is where it hurts. Hopefully this will get better with XNA, but currently it's a real show stopper.I'm pretty sure one of the earlier .NET frameworks (1.1?) is a standard OS component, and I know that 2.0 is part of Windows Vista.
Distribution problems can seem daunting but they can all be solved with a little effort. Again, I wouldn't let this push you away from a .NET route...
FWIW, I would personally still choose DX9/C++ hands-down over MDX because of familiarity. I am however giving serious thought to moving any future tool/editor/prototype development to C#/.NET.
hth
Jack
Quote:Original post by jollyjeffersI'm pretty sure one of the earlier .NET frameworks (1.1?) is a standard OS component, and I know that 2.0 is part of Windows Vista.
Unfortunately it isn't in XP. .NET 1.1 (not 2.0!) is suggested as an optional component in Windows Update, but I think very few people download anything but the critical updates.
Quote:Distribution problems can seem daunting but they can all be solved with a little effort.
Problem is it's not only an effort for the developer, but for the end user as well. Only a little maybe, but probably enough to repel most casual users...
I posted this list a while ago in the MSDN forums:
Making fast and complex games sometimes requires the edge that C++ gives you.
Use unmanaged code if....
* you need to optimise your code to the ultimate level such as CPU cycles, memory cache hits etc
* C++ is your language of choice anyway (though consider managed C++) - if so the productivity gains of managed code may not be big enough to outweigh your efficiency
* you prefer your API to be more stable (Sorry Tom, but MDX changing often does upset some folk) as the C++ API has been around longer and is more mature
* you want to go cross platform or consoles
* you believe the stigma of managed directx will cause your game not to sell or be published
* you want to get a job programming games with a big game studio in the near future (being realistic here - I just don't see managed DirectX in the jobs wanted ads at the moment)
Otherwise native vs managed directx should be a decision you make based on what you want to do, how fast you want to do it and your level of familiarity with the technologies involved.
Making fast and complex games sometimes requires the edge that C++ gives you.
Use unmanaged code if....
* you need to optimise your code to the ultimate level such as CPU cycles, memory cache hits etc
* C++ is your language of choice anyway (though consider managed C++) - if so the productivity gains of managed code may not be big enough to outweigh your efficiency
* you prefer your API to be more stable (Sorry Tom, but MDX changing often does upset some folk) as the C++ API has been around longer and is more mature
* you want to go cross platform or consoles
* you believe the stigma of managed directx will cause your game not to sell or be published
* you want to get a job programming games with a big game studio in the near future (being realistic here - I just don't see managed DirectX in the jobs wanted ads at the moment)
Otherwise native vs managed directx should be a decision you make based on what you want to do, how fast you want to do it and your level of familiarity with the technologies involved.
Quote:Original post by jollyjeffers
The native versus managed DirectX argument isn't really a substantial one - I believe the target was that blow-for-blow MDX should be within 97% of the native equivalent. I don't know if they achieved that exact target, but I'm not aware of any conclusive evidence that suggests managed is that much slower than native.
Just as a little side note in light of this statement. When I run the skeletal animation sample from the SDK sample browser I actually get a higher framerate running the managed version over the native version (max 254 fps native, 361 fps managed). I know that's not irrefutable evidence, but I just wanted to throw that out there to say that yes, the speed of MDX is, indeed, comparable to that of native DirectX, at least in some cases.
-AJ
To address the deployment issue, yes it has been a problem, but with the latest DirectX redistibutables (and the web updater) all required libraries will be installed. This includes the D3DX ones that were previously a source of serious pain.
Furthermore, through ClickOnce you can safely deploy .NET applications, which will automatically install the appropriate runtime for your application if needed. I haven't tested this with MDX apps yet, but for normal .NET apps it works like a charm.
True to some extent, but the MDX1.1 API hasn't changed much (at all?) over the last few months, so it shouldn't be an issue really. MDX2.0 is a whole different matter though, but it's been made quite clear that it's in beta, broken and shouldn't really be used. And of course Jack's advice applies here too: just don't switch API's during development.
And one more for the fun of it [smile]
This argument comes up times and again, but I've been doing some thinking on this. I won't argue about fast, this seems to be quite a subjective issue and we'll never reach a decent conclusion on this one. But on the complex side, I believe it's actually C# that gives you an edge.
Referring to Jack's design issue from a while back, he was trying to split up a complex C++ project into various modules (in the form of DLL's I believe). It turned out that this is quite hard to do in C++, particuarly when sharing object types across DLL's. In C#/.NET, the CLR takes care of all this for you, making the use of the physical assemblies completely transparent for the coder. Combining this with the language structure of C# and the nice API (admittedly a matter of taste), I'd recommend C# as the prime choice for complex projects.
Sorry, I don't intend to start yet another C++ vs C# thread, but I thought I might actually have a point here [wink]
[Edited by - remigius on May 30, 2006 3:56:01 PM]
Furthermore, through ClickOnce you can safely deploy .NET applications, which will automatically install the appropriate runtime for your application if needed. I haven't tested this with MDX apps yet, but for normal .NET apps it works like a charm.
Quote:you prefer your API to be more stable
True to some extent, but the MDX1.1 API hasn't changed much (at all?) over the last few months, so it shouldn't be an issue really. MDX2.0 is a whole different matter though, but it's been made quite clear that it's in beta, broken and shouldn't really be used. And of course Jack's advice applies here too: just don't switch API's during development.
Quote:Making fast and complex games sometimes requires the edge that C++ gives you.
And one more for the fun of it [smile]
This argument comes up times and again, but I've been doing some thinking on this. I won't argue about fast, this seems to be quite a subjective issue and we'll never reach a decent conclusion on this one. But on the complex side, I believe it's actually C# that gives you an edge.
Referring to Jack's design issue from a while back, he was trying to split up a complex C++ project into various modules (in the form of DLL's I believe). It turned out that this is quite hard to do in C++, particuarly when sharing object types across DLL's. In C#/.NET, the CLR takes care of all this for you, making the use of the physical assemblies completely transparent for the coder. Combining this with the language structure of C# and the nice API (admittedly a matter of taste), I'd recommend C# as the prime choice for complex projects.
Sorry, I don't intend to start yet another C++ vs C# thread, but I thought I might actually have a point here [wink]
[Edited by - remigius on May 30, 2006 3:56:01 PM]
Quote:Original post by u235
Just as a little side note in light of this statement. When I run the skeletal animation sample from the SDK sample browser I actually get a higher framerate running the managed version over the native version (max 254 fps native, 361 fps managed). I know that's not irrefutable evidence, but I just wanted to throw that out there to say that yes, the speed of MDX is, indeed, comparable to that of native DirectX, at least in some cases.
-AJ
What are the names of the executable files that you're comparing? I looked in the sample browser and assumed that you were running csSimpleAnimation.exe vs. SkinnedMesh.exe? It would seem that those apps aren't doing the same thing so it's not a fair comparison.
Try running the ProgressiveMesh sample apps (csProgressiveMesh.exe vs. csWProgressiveMesh.exe vs. ProgressiveMesh.exe) for a more meaningful comparison.
One thing that people fail to mention is the increase in working set of a managed vs. native app. Bring up TaskMan and have a look at MemUsage and Page Faults between the two apps. Depending on your target audience, this might not make any difference, but if you're aiming for lower end (or mobile) platforms, the increased memory requirements would tend to favor native code. Of course, if you're the type of person that can't help but write leaky code, you might actually use less memory in the long run by writing a managed app. ;)
Quote:Original post by remigius
To address the deployment issue, yes it has been a problem, but with the latest DirectX redistibutables (and the web updater) all required libraries will be installed. This includes the D3DX ones that were previously a source of serious pain.
Its better, but its not enough to satisfy the majority of people out there who want an easy way to have a single, small as possible installer.
Quote:Furthermore, through ClickOnce you can safely deploy .NET applications, which will automatically install the appropriate runtime for your application if needed. I haven't tested this with MDX apps yet, but for normal .NET apps it works like a charm.
It kind of works, if you like to break the SDK EULA - it copies all the assemblies into your setup. It doesn't appear to understand that the managed assemblies rely on the native ones though so you don't get D3DX_NN.dll
Quote:Quote:you prefer your API to be more stable
True to some extent, but the MDX1.1 API hasn't changed much (at all?) over the
I've spent 2 years trying to convince people of that but nobody like to listen becuase they all remember the Summer04 upgrade that broke all the books and all the web tutorials (yes summer 04). Just as people were fogetting it MDX 2.0 happened.
Quote:Quote:Making fast and complex games sometimes requires the edge that C++ gives you.
This argument comes up times and again, but I've been doing some thinking on this. I won't argue about fast, this seems to be quite a subjective issue
I did say SOMETIMES :-) For the purposes if this argument I'm talking about the sort of performance that requires you to be using VTune and otehr low level tools to organise your memory and cache hits. When you get to that level there is no way that managed code will win - at least not till the JIT compiler can do memory analysis on the fly.
Quote:But on the complex side, I believe it's actually C# that gives you an edge.
Valid point.
The list isn't supposed to start any wars, it was just my observations from all the MSDN posts of where C++/Native has to best benefits. Much as I would prefer the whole world do MDX there are absolutly places that C++/Native makes sense and the industry isn't going to do a flip any time soon.
Quote:Its better, but its not enough to satisfy the majority of people out there who want an easy way to have a single, small as possible installer.
...
It kind of works, if you like to break the SDK EULA - it copies all the assemblies into your setup. It doesn't appear to understand that the managed assemblies rely on the native ones though so you don't get D3DX_NN.dll
Agreed, but I was thinking that once you can be sure you have the appropriate CLR installed, you might do all kinds of nifty things in C#/VB.net to find out if the correct MDX libraries are available. Rather than relying on the EULA breaking assembly redistribution, you could run the DirectX web updater. Admittedly not the cleanest solution and I have yet to implement this, but I think it shouldn't be too much of a problem.
Also I think the "single, small as possible installer" argument is a bit overrated. If you're talking about a complete game, the size of the .NET Runtime or DX Redistributable should be negliable compared to the media resources. And both can be installed 'on demand' over the web, making the installer smaller anyway. As long as people are downloading certain betas of 3GB+ though, this is a moot point anyway [wink]
Quote:
...
The list isn't supposed to start any wars, it was just my observations from all the MSDN posts of where C++/Native has to best benefits. Much as I would prefer the whole world do MDX there are absolutly places that C++/Native makes sense and the industry isn't going to do a flip any time soon.
All valid points [smile] C++/Native certainly isn't obsolete and I'm not on an MDX crusade, but I thought I'd throw in my observations as well.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
