Jump to content
  • Advertisement
Sign in to follow this  
147

DirectX11 which programming language?

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

As the topic title indicates, I want to know which programming language is best for programming DirectX11? I know, that C++ in the most cases is the fastest, but I also read, that C# can also be used for DirectX programming. How much is the speed difference, or are there other advantages or disadvantages for C# / C++?

Share this post


Link to post
Share on other sites
Advertisement
Most of my DirectX learning involved converting DX Samples -> C# and with the exception of startups being slightly slower in C# (although compile times make up for that) I never noticed any performance issues. Plus it was so easy to understand DirectX with less code and no COM crap

Even with terrible programming ;) I have had constant frame rates and nice performance. I had this C++ vs C# issue several months ago, not because of performance but because of almost every tutorial, guide, book was in C++, I suppose thats the downside of doing things in C#, they can all be converted but sometimes you get frustrated with translating;

You dont have to stick with just one language either, you are free to make use of both, personally I say use C# until you know 100% that you need C++ take advantage of both languages but only when you need to, chances are you wont ever need to use C++

I have recently become very fond of using C++ and C# together, it feels so taboo ;) Anyway whatever you are planning on doing will get done very quickly in C# and probably easier to change to careless of what is offered in C++, especially UI related work, which I found to be a pain in DXUT

Share this post


Link to post
Share on other sites
If I undestood both post correct, C# is a Little bit slower, but easier to use. I also write C# since 2 years, which was an Advantage of using C#. Are there any Features of DirectX11 unusable with C#? And if there aren't very big differences in the use of DirectX, it should easily be possible to later convert the C# code to C++. Is the wayof execution the same as with normal C# (the code gets compiled to a code, which gets compiled with the JIT during runtime? Also I wanted to know if a type check is made only in the code of C# or also in DirectX, if I use it with C#?

Share this post


Link to post
Share on other sites
Microsofts directx wrappers to the .net framework have all been discontinued apart from XNA which uses directx 9 so is a little out dated and won't give you the low level access you want. Slimdx is a 3rd party wrapper and seems to be the way most people go with C#/other .net languages.

C++ is usually compiled straight to native code so doesn't need the .net framework (although there is also a variant of C# for .net). C#'s slowness compared to regular C++ only really comes down to the .net framework, any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).

C# is easier to use than C++. Through slimdx you get the full feature set of dx9, dx10 and dx11, through microsofts outdated wrappers you get full access to dx9 only and through XNA you don't tend to get much access to directx itself but it does use dx9 under the hood.

Slimdx class names etc I believe are slightly different than native C++ directx but conversion of code over to C++ should be possible. Chances are you won't have performance issues on C# anyway, at least not until you start hitting AAA graphics and physics etc that aren't normally possible for a single developer

Share this post


Link to post
Share on other sites
Heh... Back when I started learning DX, I was programming in Visual Basic.
Use whatever you're comfortable with, especially if you are just learning and creating smaller scale graphical applications.
Whether you are using one language or the other, the Direct3d pipeline is the same.

For bigger scale project, I would recommend C++. If you are using C# for a large project and have done everything you could to get proper performance in vain, then porting a whole application to a more performant language will suck major balls. Edited by french_hustler

Share this post


Link to post
Share on other sites
Now my last two questions. Are there any resources/tutorials that are written in C# (only for the start, a simple example would be enough)? And, theoretically, if I writte the graphic component in C#, should it be possible to write the rest in C++, or am I wrong at this point (I mean that the parts, which consume more CPU power get written in C++, the rest in C#?

Share this post


Link to post
Share on other sites
Its possible to link unmanaged DLL's into .net applications, not necessarily an easy process (these basically include C++ class libraries etc) and accessing them is usually done through a .net class laid over the top of the unmanaged code, this is often referred to as a wrapper. Slimdx for example, you make a call to slimdx and then slimdx goes off and makes the calls into the directx library. A simple function like print4squares() will be able to be called with just that one line in a C++ application. If the function is written in C# then it can be called from a .net application with 1 line aswell. But calling it in an unmanaged DLL from .net it might require 5 or 6 lines of code before you get to being able to type the line you need hence why wrappers exist, with the wrapper you only have to type the one line of code again and it deals with conversion for you. Wrappers are still alot faster than straight porting a library to C# though. For example MOgre and Axiom are both versions of Ogre3d for .net. However MOgre is a wrapper around the original C++ library and Axiom is Ogre3d ported straight over to full C# code. With the same demo sample in MOgre I get 2 fps lower than the reference Ogre3d implementation (with a framerate in the multiple hundreds this is hardly significant) but on Axiom I can only achieve around half the original Ogre3d frame rate.

For 1 game I think just going with a single language may be much simpler. C# is still pretty fast and most of the time graphics will be through a wrapper and hardware accelerated. Axiom is probably one of the only non wrapped graphics libraries out there for .net. Physics will depend on what route you go down, rolling your own or using an existing library. Once again alot (but not all) physics libraries for .net are wrappers for existing C++ libraries but unlike graphics probably won't be hardware accelerated (unless you are using PhysX for which there is a .net wrapper for and also happen to have an NVidia graphics card, Bullet also has hardware acceleration as a user option but this is on a recent version that doesn't have a .net wrapper yet). A beginners indie game will be fine in C# coded properly. If you think you can cope with C++ though then by all means go for it. Just to show what .net can do (specifically XNA, not known which language, I assume C#): [media]http://www.youtube.com/watch?feature=fvwp&v=OiGADgezjC8&NR=1[/media]
this is of course just rendering, no physics (I think, the water has waves in it but whether theres any actual physics calculation or its just a pre coded effect I have no idea) or AI going on but damn its pretty. Edited by 6677

Share this post


Link to post
Share on other sites
If the other components expose a COM interface you can just add a reference and use the interface directly. Releasing is a bit fiddly but not much, otherwise it's quite straightforward (I've done evil things such as Lotus Notes (spit) interop before, so I can be fairly certain this works!) If you don't want that you could otherwise just write them as standard DLLs and use dllimport. See http://msdn.microsof...8(v=vs.71).aspx for some more info. Edited by mhagain

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!