#### Archived

This topic is now archived and is closed to further replies.

# C++ vs C# for Directx Development

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

## Recommended Posts

Is C# as capable as C++ for directx development? I have done some Java and some C++ in the past. Would C# be recommended for someone that is less experienced? My needs are specificaly in the area of direcinput.

##### Share on other sites
Simply yes. Aparently DirectX under c# with all the .net stuff runs 7% slower than none-net hence most people will probably use unmanaged C++. However if rapid development with .net is as advertised the 7% drop may be acceptable

##### Share on other sites
Yes I think going with C# is the right way. I really depends on your performance requirments, but when the people at microsoft say that productivity is increased, they aren''t lying. But I know how Game Programmers will often die for that extra 7%(Me included), so you may want to wait till longhorn comes out. Then, Managed Code will be built into the operating system, so the performance decrease should get smaller, so that it is only 1% slower than Native code.

Sagar.Indurkhya

##### Share on other sites
c# is slightly slower than unmanaged c++ now, but experts thinks it maybe faster than c++ in a few years (because of JIT compilation)

and the productivity gain is HUGE. trust me, or better try it !

##### Share on other sites
I agree with everyone here. I have just started learning directx and c/c++ 3 months ago and starting out with c# would have been much easier and faster. If you are that worried about native code you can also switch back to using it in the c# code because it allows for both. C# is also much easier to learn than c++.

CS Teacher-"Game Design? Why would you want to do that?"
Me-"Because it involves some of the most advanced programming with the hardest problems ever seen."
CS Teacher-"I know that! Why don''t you take my programming classes then?"
Me-"Sorry, but frankly, your classes suck."

##### Share on other sites

- C# is a huge time-saver (cuts your development time significantly). You don't want to micromanage memory for lots of parts of your code, and garbage collection handles that for you. For parts that you want to micromanage, or if you think garbage collection's bad, you can always use unsafe code.

My point is: In talented hands, C# can be fast enough. Perhaps not as C++ because of JIT compilation, but:
* That (JIT compilation) only happens once
* It's continually improving
* It allows optimization on execution, i.e. say a new technology (SSE3) comes out, the JIT compiler would then optimize the code using it without your intervention. Of course compilers aren't that perfect at optimization, but still, the time-saving is huge, and the optimization should be good enough (how often do you have to code something in assembly?).

- Managed DX is just a thin wrapper around the unmanaged API. As such, you'll almost never be limited by Managed DX itself. You'd be limited by other parts of your engine, *if* you're not good enough at C#.

- The problems we see with managedDX:
1. Requires good-to-excellent C# knowledge in order to get things running as smooth as possible (required for games, and differs with the kind of game. e.g. FPS vs Puzzle). C# is a new language, and we're not good enough at it yet.

2. There's so much C++ knowledge and resources available around (sometimes referred to as C++ inertia). This isn't a big deal, IMO, because the switch from C++ to C# is very easy.

3. For downloadable games, you're kind of limited by the size of .NET (~20 MB). Most indie games are downloadable, and using .NET would render that impossible (and many users haven't even heard of .NET yet , it seems.). Broadband and Longhorn are our saviours here.

Bitwise account: MHaggag -

[edited by - Coder on March 20, 2004 6:27:20 AM]

##### Share on other sites
hey
that some good info there but what im looking for is having the Directx stuff and all the performance critical stuff in C++ and then having C# as a Scripting language/control agent that interacts with the C++ code but doens;t run any Directx calls its self. I don;t really want to port all my C++ code that i have at the momment into c#. im just looking to integrate a scripting language of sorts and just thought C# would be nice

Eul0gy^

##### Share on other sites
quote:
Original post by Eul0gy
hey
that some good info there but what im looking for is having the Directx stuff and all the performance critical stuff in C++ and then having C# as a Scripting language/control agent that interacts with the C++ code but doens;t run any Directx calls its self. I don;t really want to port all my C++ code that i have at the momment into c#. im just looking to integrate a scripting language of sorts and just thought C# would be nice

Eul0gy^

We currently don''t want to port our C++ code to C# as well (for the aforementioned reasons). What we do, however, is create every part of our engine as a COM component. That way, we can access it easily through C#. So if we write the editor in C#, we can use the core of the engine through COM interop. And if we decide to port the C++ engine to C# someday, we don''t start from scratch. We just convert component by component.

Bitwise account: MHaggag -

##### Share on other sites
i use c++ because i don''t want to be locked in, but its stupid because i don''t really know anything else about c++ apart from using directx.

if you don''t care about being dependent on microsoft , c# n directx is fine

##### Share on other sites
quote:
Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

Bitwise account: MHaggag -

##### Share on other sites
quote:
Original post by Coder
quote:
Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

Bitwise account: MHaggag -

I wholly agree with .NET becoming a standard. Although many people hate being dependent on Microsoft, there is nothing they can do about it. Trust me on this: the average computer user is not going to try saving a couple hundred \$''s to be hassled by Linuxes non-user friendlyness. And if the avg. user is high on Microsoft, guess what operating system we developers are attracted to developing on? You got it! Microsoft Windows!!!
So rest assured the .NET standard is here to stay.

Sagar Indurkhya

##### Share on other sites
C# is much easier than C++, also for DirectX programming.
However, the Managed DirectX isn''t that good ;-/

There are already some c# engines you can use like:
Purple# www.bunnz.com
Axiom axiomengine.sourceforge.net

##### Share on other sites
AP: What''s not so good about unmanaged DirectX?

I''ve not used DirectX before and I''m a C# newbie, but what I''ve seen of both might just win me over from C++/OpenGL. I''m seriously hacked off with C++ in particular: everything takes so long to develop compared to C# or Java. IME, at least.

What do people think about cross-platform capabilities of .Net? Obviously DirectX won''t work, but OpenGL might?

##### Share on other sites
quote:
Original post by Anonymous Poster
C# is much easier than C++, also for DirectX programming.
However, the Managed DirectX isn''t that good ;-/

Well, i found Managed DirectX very good
Its even much simpler than regular, unamanaged DirectX... Try to use DirectSound for example. Or, even better, how do you play MP3 file in unamanaged DirectX? In Managed DirectX it is done by a single line of code
It really takes much of .NET stuff, like massive overloading, enums, properties, collections... can use ''foreach'' for device enumeration and similar stuff...

And please dont tell me that it performs bad in Axiom engine, its like saying that openGL sucks because it works bad in Unreal engine...
Its problem in Axiom engine coding, not managed DirectX...

##### Share on other sites
Current managedDX shortcomings/problems:
- Some bugs in D3DX functionality (especially mesh functionality, it seems). These can waste a lot of your time if you bump into one of them.
- No DirectShow.

Bitwise account: MHaggag -

##### Share on other sites
Sorry, I meant:
However, the Managed DirectX _docu_ isn''t that good

##### Share on other sites
quote:
Original post by Coder
quote:
Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

If you''re working with DirectX you''re pretty much tied to Windows anyway, it''s kind of a moot point. It would be quite a long time before Mono/dotGNU AND DirectX (DirectGNU?) could be done to a reasonable level of performance.

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites
quote:
Original post by DrunkenHyena
quote:
Original post by Coder
quote:
Original post by johnnyBravo
if you don''t care about being dependent on microsoft , c# n directx is fine

That''s one big misconception about dotNET. dotNET is a standard now, and there are two open-source implementations under development: dotGNU, and Mono

If you''re working with DirectX you''re pretty much tied to Windows anyway, it''s kind of a moot point. It would be quite a long time before Mono/dotGNU AND DirectX (DirectGNU?) could be done to a reasonable level of performance.

I have to greatly disagree here, Ken
As far as I know, Tom Miller wrote the managed DirectX layer alone. Maybe I''m wrong, but still, the managed layer is a very thin layer that can be *easily* written around GL instead.

As for the performance, that''s not much of an issue IMO, because we''re only wrapping. Minimal time is being spent in the .NET layer.

The problem with mono and dotGNU, is that they''ve got a *lot* of missing functionality, and they''ll need a lot of time to do it, based on their current pace (and when they do, MS will have released .NET 2.0, most probably).
I''ve actually attempted to help the guys (by participating in development), but - as always - was killed by the difficulty of getting linux-centric stuff to run on windows (so that I can code under windows). It needs Cygwin to run on windows, so I downloaded it. Still, it complains about missing tools, and I was so annoyed after that that I''ve ignored it for a while (and now I don''t have time ).

I still do hope that I''ll be able to do something for dotGNU sometime.

Bitwise account: MHaggag -

##### Share on other sites
quote:
Original post by Coder
I have to greatly disagree here, Ken
As far as I know, Tom Miller wrote the managed DirectX layer alone. Maybe I''m wrong, but still, the managed layer is a very thin layer that can be *easily* written around GL instead.

As for the performance, that''s not much of an issue IMO, because we''re only wrapping. Minimal time is being spent in the .NET layer.

The managed DirectX layer is a DX layer on DX, the mapping is trivial. Mapping D3D to OGL isn''t a big deal, it''s been done many times before. What about D3DX? That is a huge amount of highly optimized code with a lot of proprietary IHV info in it. Easy to replicate? I don''t think so.

What about DirectInput and DirectSound and so on? Not to leave out DirectDraw either since it''s in Managed DX.

Like dotGNU/Mono/etc it''s easy to hit some of these and claim it''s been done, but realistically to have a DirectX emulation layer with similar performance is a really big deal. Wrapping the core D3D code is a drop in the bucket, it''s the rest of DX that will be the issue.

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites
quote:
What about D3DX? That is a huge amount of highly optimized code with a lot of proprietary IHV info in it. Easy to replicate? I don''t think so.

- There''s no need to provide a helper library that is as fast as D3DX. Remember that the suggested goal is not to replace DirectX on windows, it''s merely making it portable. This port doesn''t need to be as optimal as the windows one, it just has to be good enough to run things at reasonable speeds. It''s better than nothing

Heavy-weight engines are still being written in C++. I think that the next couple of years will see light-weight apps/engines/games being written with managedDX (by lightweight, I mean games that don''t do loads of processing, and winforms-based multimedia apps)
- Many Many games have been released *without* D3DX (on windows and other platforms) and have excellent performance. It''s quite possible and relatively easy, if you have those who can do it. Given that dotGNU/mono are open-source, they''ll most definitely find some interested assembly hackers
- There are free, optimized math libraries available from AMD and Intel (and others as well)
- What are you referring to regarding proprietary info, exactly? Cache sizes and similar? These can be retrieved via DX9 for DDI9 drivers, as far as I recall, so you can do that for all the cards that support it and use that info.
Even if these aren''t replicated, it''d still be OK to live without them (Using a common-sense cache-size would work good enough for most types of hardware, for example).

quote:
What about DirectInput and DirectSound and so on? Not to leave out DirectDraw either since it''s in Managed DX.

- For sound, there''s OpenAL. It''s not as deep as DSound, as far as I know, but it''d get you the most important functionality done. i.e. You can ship with it.
- Basic input support in any OS covers the essential ground. Using that, you can get the very common immediate/buffered keyboard and mouse input to work right (and that covers the FPS/RTS/RPG genres, at least).
If there''s more advanced input support on *n{i,u}x-based systems - even if it''s not as uniform, or full-featured as DInput - you could get some sticks and pads running too.
- DirectDraw is basic hardware-accelerated 2D output. XFree86 ships with drivers supporting 2D drivers for almost all hardware, and 3D support for many/most (not sure about this 3D thing). I don''t think it''d be that hard to do the most commonly used DirectDraw functionality. Not sure about the more advanced DDraw stuff.

The point is, for anything exposed by some DirectX API, but we can''t do, we do one of the following:
- Report it as not-supported (through the caps system)
- Fallback to a reasonable lower setting that''d work
- Fail

Bitwise account: MHaggag -

##### Share on other sites
quote:
Original post by Coder
- There''s no need to provide a helper library that is as fast as D3DX. Remember that the suggested goal is not to replace DirectX on windows, it''s merely making it portable. This port doesn''t need to be as optimal as the windows one, it just has to be good enough to run things at reasonable speeds. It''s better than nothing

Considering a lot of the reaction to the idea of writing games in C# because of performance issues, I think you''re greatly underestimating the demands of the developer community. C# can already do most games at reasonable speeds, but for a lot of people that isn''t enough.

quote:

- Many Many games have been released *without* D3DX (on windows and other platforms) and have excellent performance. It''s quite possible and relatively easy, if you have those who can do it.

Everything is relatively easy if you have the people who can do it. Indie/hobby developers need all the advantages they can get and often don''t have a team to fall back on specialized knowledge.

quote:

Given that dotGNU/mono are open-source, they''ll most definitely find some interested assembly hackers

And they will work on it while it is interesting and on the bits they like. This is why really large projects like this tend to fail. Parts get done exceptionally well, other part reasonably well, and some others not at all.

quote:

- For sound, there''s OpenAL. It''s not as deep as DSound, as far as I know, but it''d get you the most important functionality done. i.e. You can ship with it.
- Basic input support in any OS covers the essential ground. Using that, you can get the very common immediate/buffered keyboard and mouse input to work right (and that covers the FPS/RTS/RPG genres, at least).
If there''s more advanced input support on *n{i,u}x-based systems - even if it''s not as uniform, or full-featured as DInput - you could get some sticks and pads running too.

There''s a common thread here. You can just use (fill in blank), but it doesn''t do everything DX does.

quote:

The point is, for anything exposed by some DirectX API, but we can''t do, we do one of the following:
- Report it as not-supported (through the caps system)
- Fallback to a reasonable lower setting that''d work
- Fail

The point is that this is unacceptable if you''re porting DX. Overall there would be a lot of missing functionality. A DX port (just like a .Net port) is only generally useful if it has the same depth and coverage.

I''ve seen a lot of projects like this in the past. They all seem to fall apart when people realize the enormity of what they''re trying to do. OpenAL will get you the core DS functionality, but it''s not much of a port unless it does virtually everything DS does. That''s the difference between an API that''s DX-like and a port of DX.

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites
There will probably be quite some time before we see the first commercial game coded in c# though. So if you want to work as a games programmer, you''ll need to learn c++ anyway. That is the situation here in Sweden.

##### Share on other sites
I think Indie developers will be releasing .Net games long before it becomes common among commercial developers. Indies have less invested in a single technology and many game styles that are popular among indies don''t require every last ounce of CPU. Also any increase in productivity (which C# claims to deliver) is like gold.

Stay Casual,

Ken
Drunken Hyena

##### Share on other sites
First of all, sorry for the long delay. Here goes...

quote:
Considering a lot of the reaction to the idea of writing games in C# because of performance issues, I think you''re greatly underestimating the demands of the developer community. C# can already do most games at reasonable speeds, but for a lot of people that isn''t enough.

It depends on what developer community we''re talking about. For seasoned proffesionals, I don''t think there''s much of a point here.
- They usually have their cross-platform GL/DX engines anyway.
- Their titles are usually heavy-weight, and do benefit from optimization, down to the assembly level (When patching Halo PC, gearbox software even had to remove the effects framework to gain performance)

For most of the indies, I think C# fits quite nicely. From a technical standpoint, their games are very lightweight, relying more on design than technical excellence (Most of this year''s IGF entries are lightweight)

quote:
Everything is relatively easy if you have the people who can do it. Indie/hobby developers need all the advantages they can get and often don''t have a team to fall back on specialized knowledge.

Hmmm. That''s a good point, I missed that
Still, on the topic of math libs, there are free math libraries out there (like Intel''s/AMD''s)

quote:
And they will work on it while it is interesting and on the bits they like. This is why really large projects like this tend to fail. Parts get done exceptionally well, other part reasonably well, and some others not at all.

- It''ll always be interesting, in this specific project (writing an optimized math library is interesting)
- Indeed, open-source projects usually suffer from this. Documentation, for one thing, is one of those parts that aren''t interesting to work on. Most open-source libs/products suffer from bad documentation (compared to microsoft''s professional docs, for example).
People need to get paid to work on these things (JoelOnSoftware.com says microsoft had a guy solely responsible for links in some Excel documentaitons, for example).

However, that doesn''t mean they "fail". Linux didn''t. Gimp didn''t (And it actually has a somewhat nice documentation). They leave many things to be desired, yes, but still, that''s much better than nothing.

quote:
There''s a common thread here. You can just use (fill in blank), but it doesn''t do everything DX does.
quote:
The point is, for anything exposed by some DirectX API, but we can''t do, we do one of the following:
- Report it as not-supported (through the caps system)
- Fallback to a reasonable lower setting that''d work
- Fail

The point is that this is unacceptable if you''re porting DX. Overall there would be a lot of missing functionality. A DX port (just like a .Net port) is only generally useful if it has the same depth and coverage.

- I disagree. It''s completely acceptable. Say you''re going to make your engine/game cross-platform, using DX on windows, and other APIs on other OSes (like id do, with the exception of D3D). You''ve already sacrificed the-features-in-DX-but-not-in-others when you''ve written a port. So if we "removed" the burden of writing-a-port, by using those other APIs on non-windows OSes, it''s only a win.

- A port of .NET without the whole ASP.NET namespaces, and the whole security APIs, for example, would still be super useful. 99% percent of end-user apps don''t use those. By covering common functionality only, the situation only gets loads and loads better. Just having WindowsForms to be cross-platform is excellent.

- Another point is: Look at the indie (and even professional) games out there. How many of these depend on very-advanced-features not found in non-DX? And how much would the game be affected?

quote:
I''ve seen a lot of projects like this in the past. They all seem to fall apart when people realize the enormity of what they''re trying to do. OpenAL will get you the core DS functionality, but it''s not much of a port unless it does virtually everything DS does. That''s the difference between an API that''s DX-like and a port of DX.

- Fine. Let''s say that it''s an API that''s DX-like. Is that bad? No. It''s definitely better than not having it at all.
- Regarding failure, there are a lot of advanced Open-source projects that haven''t failed. Linux, Gimp, Apache, SharpDevelop, cvs, ...etc.
The point is, if the project is useful enough to be used, people will contribute. Also, sponsoring can make things better (SharpDevelop, and mono are sponsored, for example).

Now regarding the project-usefulness thing a couple of lines above. This has brought something to my mind. It seems to me that people writing a cross-platform .NET based mutlimedia library that''s NOT DX-based has actually a higher chance of happening. After all, they:
- Won''t have to abide to Microsoft''s interfaces, and keep their lib updated whenever Microsoft does a change (and Microsoft does that often)
- Will not strengthen Microsoft''s/Microsoft-product''s position
Internally, that lib could use DX. Just like OpenAL does (it uses DirectSound on Windows-platforms, if I recall correctly).

The problem with that is the same problem we face now. You''ll have two APIs:
- One is cross-platform, but somewhat lacking in features, and not regularly updated.
- One isn''t cross-platform, but regulary updated with great features.

From a developer''s perspective, that''s not a bad thing, given that the gaming market is windows (currently, and for some long time it seems).
However, it does annoy me having to do windows-only games when there are other promising platforms out there, that could do with the support (I''m not saying we''re doing heavy-weight blockbusters or anything close to that here. It''s just that even having good indie-weight games on non-windows platforms is supportive, healthy, and refreshing.).

Finally, I''ve just got to say thanks for the nice discussion so far

Bitwise account: MHaggag -