Input Needed: Tests for C#'s future validity as a game programming language

It's a bit Linux-centric, but you can find a number of language benchmarks at http://shootout.alioth.debian.org.

C# is fine for making games.

Most people just do not like change. The fact is, C and C++ have been around a long time and have constantly stood the test of time, weathering every single "next best thing" to come around. This puts alot of points in the "pro" column. But...

This doesn't mean that C and C++ are the best programming languages ever. They do certain things very well. They are certainly the most popular. Another fact though, is that game development is becoming more and more like other industries: It's a cost and quality vs. performance issue.

Once someone learns C# and the .NET library, their productivity will go through the roof. The human eye cannot distinguish past 30 frames per second so framerate is not a great argument to make here. Modern processors are so fast and C# performance is so close to C++ performance, that, to me, the time saved in development is worth the minimal performance hit you take from running in a managed environment. Don't worry, there'll be plenty of cycles around for your physics and AI ;)

But from an industry perspective, what is more important: avoiding memory leaks, obscure bugs, and getting the game out the door months faster....or...having some kid with a $3000 alienware rig get 238 FPS instead of 250?

C# is teh pwn, especially for making tools and other winform intensive programs.

But whatever, dude. The MDX samples already run the same speed in C# vs C++. It's all the same.

C# is fine.

I'm is sceptical about floating point math performance, and other cpu-intensive things, and doing many operations with vectors (e.g. java was very bad at it while Sun claimed same performance), but it doesn't matter too much in today's games. Also, it is definately easier to code in C# than in C++ , and you can develop working game faster, or in same time, make better game. It is especially true if you are short on human resources(e.g. are developing it alone). As about memory - garbage collectors generally eat more ram, but you don't get memory leaks, so overally, it depends who is better.

If you want to make uber-kickass game and have ton of experienced developers, well, it's proven that C++ can do it, and experienced developers most likely are familiar with C++, so in this case C++ will be better. Also, if you want to use existing physics library or other middleware that doesn't have interface to C# , that'll be problematic.

[shudder]It's spelled a lot, not alot.[/shudder]

High frame rates don't matter at all if the product is never finished. I find actually finishing something much easier in C#, which is why I switched. Can C# make good games? Of course it can make good games. A game doesn't need to be blazingly fast to be good and sell well. I suspect the very top games in terms of graphics will always be written in C/C++, but most developers will switch over to one managed language or another.

i'm making a 2D MMORPG in C# and getting 60~FPS :)


Picture 1
Picture 2

~60 FPS because you have VSync on? [wink]

What advantanges does C# provide in terms of game programming? I don't know much about it, but I'm sure it's great for building GUIs and dragging and dropping things and so on. But what about for games?

One big disadvantage is that it is unlikely to be supported on many console platforms (PS3 comes to mind), and makers of libraries and middleware may not want to expend effort on it for that reason. So that's a productivity argument also.

And I don't want to sound like a curmudgeon here, but an argument like "Well, modern computers are so fast that you won't even notice the speed difference!" is very weak. Task complexity always expands to fill all available resources. There will be situations in which you do want the extra speed or memory (if any). Now it may be the case that C# allows you to program in a way that's just as fast as C++ or C, just like, if you want to, you can avoid many C++ features and program C++ in what is more or less C. And I would also agree that 80% of the time you should do whatever lets you be most productive. But for that other 20%, you have to focus on whatever is best for the end user, even if it means jumping through some crazy hoops. No doubt this is more true for shipping shrinkwrap games (especially on consoles) than for hobby projects.

(BTW the human eye can easily distinguish between 30 and higher fps rates. Or, would you claim that I don't have human eyes? :)

And it's true that nothing about C++ or C# _inherently_ makes a game more or less fun, but this _is_ a programming forum, not a design forum, so we are talking about efficiency and optimiziation...

Not that I hate C# or anything, I am truly curious about what advantages it provides.

Oh...as for profiling tests:

I'd find some sort of physics demo, with source, on the net that does a lot of collision detection and interaction. That's a good measure of what takes up a lot of CPU (as opposed to GPU) time in modern games.

Another option would be to build and run and time a raytracer, again from some open source, in each environment. Games don't do real raytracing generally but in some ways the types of operations are similar.

Quote:

Once someone learns C# and the .NET library, their productivity will go through the roof. The human eye cannot distinguish past 30 frames per second so framerate is not a great argument to make here. Modern processors are so fast and C# performance is so close to C++ performance, that, to me, the time saved in development is worth the minimal performance hit you take from running in a managed environment. Don't worry, there'll be plenty of cycles around for your physics and AI ;)

People need to stop propagating such FUD. Human vision can distinguish flickering stimuli up to 60 Hz according to tests... And from my experience, some people can distinguish even more. 24 FPS is for cinema, with images that incorporate motion blur (antialiasing in time). TV works at 30 FPS, but actually displays images at 60 Hz interlaced to counter flickering. The fact that you can get an impression of smooth motion at 24/30 FPS does not mean you can't appreciate anything faster, and does not really apply to videogames with renderers that produce images with no AA in time.

And please, do not, ever, compare languages in terms of running time. That is purely compiler, platform and application specific.

Quote:

But from an industry perspective, what is more important: avoiding memory leaks, obscure bugs, and getting the game out the door months faster....or...having some kid with a $3000 alienware rig get 238 FPS instead of 250?

Whats faster to code in C# is the GUI, and thats because microsoft never released a real GUI API in C++ (don't tell me about MFC, please). From my experience, 95% of game code (not talking about tools here) is not about that. Its about code that serves an actual purpose... And this code is not going to be written much faster in C# or Java than it is in C++. As for obscure bugs and memory leaks, all I have to say is, learn how to code, cause I'm pretty sure its possible to make buggy code in C# as well.

The reason C# is not catching on for everyone is that it takes away some of the freedom of C and C++, adds nothing more in respect to portability, and provides garbage collection, which goes against the very simple principle that you should free ressources that are allocated to you (very easy concept to grasp when you've been coding for over two months).

Personally, I like a language that gives me freedom. C++ is not perfect, but it gives you the choice, and that has alot of value when you know how to program well. I'm getting really sick of all the people that just want to code as fast as possible and never want to bother learning a programming language properly. They are the reason why there are so many bugs in all the software we use.

Quote:

Original post by Max_Payne People need to stop propagating such FUD. Human vision can distinguish flickering stimuli up to 60 Hz according to tests... And from my experience, some people can distinguish even more. 24 FPS is for cinema, with images that incorporate motion blur (antialiasing in time). TV works at 30 FPS, but actually displays images at 60 Hz interlaced to counter flickering.

In addition, HDTV displays images at 60 Hz non-interlaced, and the only reason for this limitation is the frequency of AC power supply (60 Hz US). The difference in frequency in Europe is the basis for PAL's 25 FPS as opposed to NTSC's 30.

Know your ergonomic factors, people.

That said, it's entirely too early to start talking about the replacement of C++ with C# - if that will even ever happen. C# still has some social and philosophical barriers in its way: everything-is-an-object, portability is still largely speculative, It Came From Microsoft™, I Don't Want To Lose Control™. The arguments being made here, both pro and con, may actually be completely beside the point. The next generation of gaming architectures are going to rely heavily on outsourcing and middleware, and we may find that a middleware component is written pedal-to-the-metal in C or C++ while exposing its interfaces to .NET via a C++/CLI (Managed C++) wrapper, allowing both native and .NET targets to leverage it.

For your game, for right now, write in whatever language both meets your needs and you are most comfortable/productive in. Period.

Quote:

Original post by Oluseyi Quote: Original post by Max_Payne People need to stop propagating such FUD. Human vision can distinguish flickering stimuli up to 60 Hz according to tests... And from my experience, some people can distinguish even more. 24 FPS is for cinema, with images that incorporate motion blur (antialiasing in time). TV works at 30 FPS, but actually displays images at 60 Hz interlaced to counter flickering. In addition, HDTV displays images at 60 Hz non-interlaced, and the only reason for this limitation is the frequency of AC power supply (60 Hz US). The difference in frequency in Europe is the basis for PAL's 25 FPS as opposed to NTSC's 30. Know your ergonomic factors, people.

And, as a matter of fact, european TVs produce a very annoying flickering effect. This is because most people can easily distinguish flickering stimuli below 60Hz. And yes, you should trust me on this matter, as I got an A in my perception course last semester, which was almost entirely about human vision. Thank you.

Quote:

That said, it's entirely too early to start talking about the replacement of C++ with C# - if that will even ever happen. C# still has some social and philosophical barriers in its way: everything-is-an-object, portability is still largely speculative, It Came From Microsoft™, I Don't Want To Lose Control™. The arguments being made here, both pro and con, may actually be completely beside the point. The next generation of gaming architectures are going to rely heavily on outsourcing and middleware, and we may find that a middleware component is written pedal-to-the-metal in C or C++ while exposing its interfaces to .NET via a C++/CLI (Managed C++) wrapper, allowing both native and .NET targets to leverage it. For your game, for right now, write in whatever language both meets your needs and you are most comfortable/productive in. Period.

Its never too early to discuss about anything. C# and .NET are coming here right now. The arguments that are being made about it mostly relate to the practical aspects of C# as a programming language. I don't find that to be "besides the point" at all. The "it came from microsoft" argument is partly besides the point, but it still has some validity... Who's deciding what's going to be in C# 2.0?

As for outsourcing and middleware... Give us a break. As a programmer, I try to rely the least possible on external dependencies, because they take away so much freedom from us, the programmers. I don't see 3D engine being made all out of "middleware" going anywhere. Eventually, what will be needed is a more standard 3D engine architecture or platform... Standards... Just like for operating systems... They all have threads, processes, memory allocation and drivers, and work in pretty much the same manner.

Quote:

Original post by Max_Payne As for outsourcing and middleware... Give us a break. As a programmer, I try to rely the least possible on external dependencies, because they take away so much freedom from us, the programmers.

Ah, "freedom." That elusive, unquantifiable mantra of the masses, particularly those with no notable credits to their names. Why should I care what you do, "as a programmer," given that I'm a programmer myself and my experience and approach is the exact opposite? Anecdotal evidence is exactly that: anecdotal. Critical analysis of the behavior of several disparate entities operating under a pressure to produce and perform, however, provides valuable insight.

Quote:

I don't see 3D engine being made all out of "middleware" going anywhere.

"3D engine" is a poor metaphor, as I hope you're aware. In reality, you have a combination of disparate components - entities from a library or set of libraries, if you will - being cobbled together to create an intermediate platform on which a game is built. Considering that Unreal 3 integrated SpeedTreeRT, considering that engine after engine is integrating Havok or some other physics "engine," considering that scene graph and renderer vendors such as Criterion (RenderWare) and NDL (NetImmerse, Gamebryo) continue to pull in a bundle... I'd say you're wrong.

But I'm not going to argue with you. I think that middleware is exploding and increasingly becoming an essential part of the game development "ecosystem," with vendors specializing in particular aspects of game development providing a product and support to developers putting together a consumer title, and the supporting evidence goes beyond the mere successes and proliferation of such vendors. See the GDC interview of David Eberly and Tim Cox of Morgan Kaufmann to hear their take and plans in terms of upcoming texts to help developers get a handle on this likely scenario.

YMMV.

Quote:

Personally, I like a language that gives me freedom.

Freedom to do what? Put some ice on your head =)

Quote:

And please, do not, ever, compare languages in terms of running time. That is purely compiler, platform and application specific.

What should we compare them in terms of then?

Practical comparisons need to be made in order to determine if there really is any appreciable difference. This is why comparisons between languages are usually made using either the same test setup, benchmarks, and/or the best available or most common setups for each language. By setups I mean latest or most common compiler versions, using the latest relevent drivers, etc.

I just find it funny because 5-10 years ago everyone was so completely anti C++. Pure C was the one and only way or you were "obviously" an idiot. Look around today though, C++ abounds.

Quote:

As for obscure bugs and memory leaks, all I have to say is, learn how to code, cause I'm pretty sure its possible to make buggy code in C# as well.

See, this is such a naive statement to me. Even the most experienced code monkey will screw up eventually. And when they do screw up, when they forget to follow a best practice, check an array boundary, throw an exception, clean up memory, WHATEVER....that's going to be costly to find and fix. All it takes is one typo. You yourself have never made mistakes like this and spent hours or days trying to figure it out? I find this hard to believe.

Quote:

Original post by Penance Freedom to do what? Put some ice on your head =)

Freedom to do pointer arithmetic and not have a "garbage collector" doing work behind my back.

Quote:

What should we compare them in terms of then?

Scalability. How easy it is to work with large amounts of code. I find that OOP greatly facilitates this. Features like templates and operator overloading help alot with scalability. In my opinion, scalability is what makes the difference between C and C++. Sure, you can make a web server in C without much problems. But try making a 3D engine, its going to be an organizational mess, thats almost guaranteed (look at the Quake 2 code for an example...).

Quote:

See, this is such a naive statement to me. Even the most experienced code monkey will screw up eventually. And when they do screw up, when they forget to follow a best practice, check an array boundary, throw an exception, clean up memory, WHATEVER....that's going to be costly to find and fix. All it takes is one typo. You yourself have never made mistakes like this and spent hours or days trying to figure it out? I find this hard to believe.

I am working on my own 3D engine project. We have over 60000 lines of code in total, and not many bugs. Most bugs are actually inappropriate behavior in the physics and such. Array boundaries and other such problems rarely happen... And when they do, they are immediatly caught by the debugger. Its extremely rare that I get memory related errors, and when I do, they are found and fixed within 3 minutes 99% of the time.

The fact is, an efficient debugger can detect memory leaks and other memory related errors pretty fine. The problem is that most people don't use appropriate tools. Things like mmgr do a very fine job at detecting memory leaks and memory corruption... Imo, tools like those should be part of any debugger.

Quote:

Original post by Max_Payne Quote: Original post by Penance Freedom to do what? Put some ice on your head =) Freedom to do pointer arithmetic and not have a "garbage collector" doing work behind my back.

That's funny, I'd consider the opposite to be more enabling, or as you put it "free."

My current projects are all in C# using managed directX / .net 2.0. I don't see myself every using C++ / OGL again frankly (for which I'm extremly happy).

The furture of game development is all about managed, multithreaded, higher level code. These are things C++ and GL fall over on.

Here is a fact that should help to convince you its a good idea:

In the DX SDK, there are C++ and C# versions of many of the samples.
An example:
There is a C++ and C# version of the 'Simple Animation' sample (called SkinnedMesh in C++) - They effectivly do exactly the same thing, draw a skinned character on screen, playing a running animation.
The thing is, the C# one is a 28k source file, the C++ one is 78k. The C# one is quite clean and fairly easy to understand, the C++ isn't. But the big thing, is the C++ one runs at 480fps, the C# one runs at 1050fps. Thats no small difference. Twice as fast, half the size, twice as easy to understand (maybe moreso).

I've had similar experience with other programs I've done.


.net 2.0 is very good. Visual studio Express is also very very good - with the one exception that I cannot find the thread window in C# express! ARGH!! :)


I'm doing a lecture in 2 days at my uni on the advantages of MDX and .net over C++/C and OpenGL. With the exception of MDX not being very cross-platform, it's pretty much a white wash.


[edit]

I'll also mention the Axiom engine. It is a C# port of OGRE that is actually faster (whereas OGRE is C++). That alone should be proof enough.

Quote:

Original post by Max_Payne As for outsourcing and middleware... Give us a break. As a programmer, I try to rely the least possible on external dependencies, because they take away so much freedom from us, the programmers. I don't see 3D engine being made all out of "middleware" going anywhere.

Thus spoke someone who has never shipped a game, I'm guessing.

You have the freedom to spend years and years reinventing the wheel. Lucky for you. I suppose you write your own compilers too?

I'm not sure what you mean by "3D engine being made all out of middleware", but games that use middleware (or even just external libraries) are common. I guess you've never heard of the Havok physics engine that shipped with Half-Life 2 and many other games? Or the Renderware engine that was used in Tony Hawk and Grand Theft Auto games? I guess those games didn't do so well, probably they made some bad choices, eh?

Or if you just want to talk about 3D engines, take the Quake 3 engine which is used in many games like Call of Duty. Those guys didn't feel the need to rewrite the engine for their "freedom"...They decided to spend some of their time making a fun game and the rest counting the money they made. I guess that was just a bad decision on their part though, eh?

The reality of the industry is that it's wasteful, arrogant, and near-sighted to assume that you're such a hot programmer that you need to write everything from scratch yourself.

Quote:

Original post by Max_Payne Scalability. How easy it is to work with large amounts of code. I find that OOP greatly facilitates this. Features like templates and operator overloading help alot with scalability. In my opinion, scalability is what makes the difference between C and C++. Sure, you can make a web server in C without much problems. But try making a 3D engine, its going to be an organizational mess, thats almost guaranteed (look at the Quake 2 code for an example...).

I feel compelled to point out that a) you can do OO in C; and b) C++ is a relatively poor language for OO.

Carry on.