• Advertisement
Sign in to follow this  

Taking My Engine Back From C#/MDX 9 to C++/DX 9...

This topic is 4287 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

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.

Share this post


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

Share this post


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

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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

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]

Share this post


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



Share this post


Link to post
Share on other sites

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.


Share this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by remigius
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.

A "complete game" doesn't have to be 500+ MB, it can be a < 1 MB game like Diner Dash or Bejeweled. In fact, I think a *major* market for .NET developers would be small casual games - if only .NET and MDX were more widely distributed or easier to install for the end user.

Many casual gamers are OK with downloading a game (as opposed to running it in the browser), but then it has to run *immediately*. An additional install process and download of components that are 30 times the size of the game itself will stop them dead in their tracks.

Share this post


Link to post
Share on other sites
Quote:
you might do all kinds of nifty things in C#/VB.net to find out if the correct MDX libraries are available.

Sadly you would have to be nimble and smart becuase MS don't document any official ways of detecting anything about DirectX. You can guees but they reserver the right to change it.

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

Saldy also breaks the EULA - I asked them them the day it came out. You are not allowed to redist this you have to ask your users to 'go to this URL and run the download'

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

Agreed for big games, but as Jonas pointed out the indie scene goes for small fast downloads. Surf around http://forums.indiegamer.com/ for a while and you will see that a lot of the indie guys who are making money are still targetting DirectX 7 or 8 to avoid downloads. I can't find the thread but there was one on there about how long before users get bored and cancel the download and it wasn't very big. XBox Live Arcade games are limited to 25Mb (50Mb if you get special permission). Thankfully XNA framework *should* mean that we don't have to worry about getting that on there. I've certainly made my opinion known the the team.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jonas B
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.

It used to be a pain to distribute the MDX runtimes, but nowadays the MDX runtimes are installed by default from the recomended DX runtimes source, The DirectX web installer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Enselic
It used to be a pain to distribute the MDX runtimes, but nowadays the MDX runtimes are installed by default from the recomended DX runtimes source, The DirectX web installer.

It's a step in the right direction, but most people don't regularly update their DX runtime. And if doesn't help when dealing with casual gamers - point them to two sites (.NET + DX) for additional downloads after downloading the actual game and they'll never play it unless it's a real killer app.

Currently I can't see any real MS efforts for pushing either .NET or MDX to end users. Paint.NET (MS endorsed) is probably one of the better "trojans" for getting .NET onto peoples HDs, and I have some hopes for TrayGames pushing the MDX install base, but it's disappointing to see the lack of commitment from MS themselves.

Share this post


Link to post
Share on other sites
Well, thank you all. =) I think I am going to go with C++. I am MORE comfortable with C++ than C#. I just started using C# about 3 months ago, MDX about 1 1/2 mo. ago. So I'll go with C++.

And I read somewhere (don't remember where =P) that if you're distributing a .NET application by CD-ROM, it's okay to include the .NET Framework Redist (dotnetfx.exe, right?). But if you just make a small game or demo, and want it available for download over the 'net, there's no point to including a 20+MB redist for the .NET Framework. It makes sense to me. =)

But thanks again. I'll stick with C++ for now. And maybe when I do some more learning/working in C#, I can port my code to C#. Thanks. =)

Share this post


Link to post
Share on other sites
I build my DLLs (ie. graphics, audio, input, etc) using C++/CLI. You get the best of both worlds in a seamless manner. I then consume these .NET assemblies from C#. It feels almost like scripting.

You must remember that in .NET, language is secondary - it's all about the framework.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement