Game development in C#

Hello,

I hope this is a relevant forum to post these questions in - I think it is because many people thinking of moving their game dev from C++ to .Net who use OGRE will be interested in OgreDotNet, like me.

So, my first question is this: Is C# a valid development language for fully fledged game development, in terms of speed from the resulting compiled code?

As far as I’m aware, C++ is the best language for developing modern day games because of the way it can optimise the compiled code. Is this correct? I have read in the Wiki that the performance degradation incurred by the OgtreDotNet wrapper (the C# code communicating with the C++ code and back) is negligible. But if all of my game logic is written in C# (A.I., physics, sound etc. everything excpet the graphics handled by OGRE) then how will this affect my executable in terms of speed compared to a game written fully in C++? Still just negligible?

My second question is related to libraries written in C#. There are tons of useful libraries around written in C++ for physics and sound etc. but how about C#? If Im wanting to start developing in C# I need to know whether there are existing libraries out there which I can use just as easy I could when I was working in C++.

Thanks for your time,

Spanner_man

C# is a very viable language for game development.

The .NET framework was slow back in the 1.0 days, but today speed shouldn't be a reason to avoid .NET. I'm sure .NET languages are still slower than c++, but not by much (say, 5-10%?). And the more rapid development time and easier debugging MORE than makes up for it.

There are .NET bindings to many popular c libraries, such as SDL, OpenAL, OpenGL, ODE and such. Look up the Tao framework for example. The likely reason that a .NET wrapper for Ogre hasn't appeared before is that creating bindings to a c++ library is an order of magnitude more complex than a c library.

Personally, the only reason I'd ever us c/c++ for anything today would be if I was doing device level stuff. And that doesn't interest me.

One note of caution though: .NET game development requires a good understanding of how garbage collection works, otherwise you'd get as many memory leaks as an inexperienced c++ user would.

Interesting question.


The .NET framework was slow back in the 1.0 days, but today speed shouldn't be a reason to avoid .NET. I'm sure .NET languages are still slower than c++, but not by much (say, 5-10%?). And the more rapid development time and easier debugging MORE than makes up for it.

Did you/someone else benchmark that? Or is this just your believe?


One note of caution though: .NET game development requires a good understanding of how garbage collection works, otherwise you'd get as many memory leaks as an inexperienced c++ would.
Doesn't C# have a garbage collector?

Did you/someone else benchmark that? Or is this just your believe?


That's based on my own experience. It's more complex than that really, because it would probably also depend on what you're doing. I'm sure some things are faster than others. Personally, I steer clear of benchmarks because they're always biased and in disagreement. I prefer to try it and find out for myself .

Regardless, one just has to look at the directx sdk: ever since managed directx was rewritten from the ground up in managed c++, rather than being a wrapper, the managed samples are just as fast as the unmanaged c++ ones.

I've yet to see a scenario where I was like "man, that's slow". I've done graphics development in C and pascal (which is just as fast as C), and don't find C#'s performance to be significantly slower. Like I said, as far as I'm concerned it's ease of use more than makes up for any minor deficiencies in performance.


Doesn't C# have a garbage collector?

It's important to remember that c# is just one language among many that use the .NET runtime (there's also jscript, vb.net, delphi.net, boo, and many more). This is why it's a myth that vb.net is slower than c#. It is the .NET runtime has the garbage collector.

The important thing about the garbage collector is that it only deletes an object once no references to it exist in your application. So if you aren't carefull to remove references to objects you wish to be deleted, they won't be. So in .NET game development you have to be just as carefull about ensuring your objects are properly cleaned up as in c++.

(aka Marc2)

I didn't test anything on this. My believe so to say is that managed DirectX and DirectX probably don't differ to much in speed. They are just wrappers to access the grafics drivers and basically, from a point of complexity, do nothing. If you write a programm that just draws stuff, cpu should idle; otherwise there won't be cpu power left for the gamelogic.

The more interesting point here is the speed in evaluating common tasks for gamelogic. An interesting benchmark would be to have e.g. an implementation of a kdtree in C++ as well as C# and compare the results for a number of nodes to insert and delete. I don't know if this has been done somewhere. As well, the "biased point" is a problem. I don't doubt you can implement a kdtree in C# that is faster than another in C++. And I don't doubt the opposite. Both implementations have to be comparable somehow.

As well, the "biased point" is a problem. I don't doubt you can implement a kdtree in C# that is faster than another in C++. And I don't doubt the opposite. Both implementations have to be comparable somehow.

Exactly, it's all about implementation. There's crappy c++ programmers, and crappy .NET programmers. Unfortunately, because .NET is easier to use, it draws more of the crappy ones and gives .NET a bad name. You can use the fastest language you can find, but if you don't know what you're doing, your performance will be hurt.

Fact is, there's benchmarks out there that say c++ is far faster, and some that say c# is the same or even faster. Hell, there's probably benchmarks that try to claim that vb 6 is faster than c++ .

If I may add an additional note about .NET garbage-collection: The .NET GC is terrible at sweep prediction when running in semi-infinite loops (which most games do). In most .NET applications (such as GUI apps using System.Windows.Forms), this isn't an issue because application events are allowed to pump and the .NET GC thread is happy (because there is idle time). The problem occurs when your app doesn't allow the message pump to properly feed information the way Windows wants it (such as when running in exclusive fullscreen mode). The .NET GC will get confused and may not run for huge stretches of time. Basically, there is no idle time in there for the GC thread to properly do it's voodoo. If your game is creating/destroying many objects per frame, or tick, this could quickly balloon your memory usage then follow that with a very nasty sweep which could actually stutter your game.

There are articles all over about this, but the most common approach I have seen to fix it (and the one I use myself) is to run GC.Collect(2); every 30 or so seconds. In 99% of cases you never want to call GC.Collect yourself...this case falls in that other 1% I pass 2 as the argument because I want to clean generations 0 .. 2, but not 3. This is a performance optimization and isn't neccescary, but generation 3 is known to be the most costly to sweep and usually has the least amount of objects in it (or should, if your GC is running often enough).

Thanks, kerion, I learned something new

Thanks for your replies guys. Im happy to hear there are C# wrappers for things like ODE and OpenAL, thats good news. Cheers.