Jayme Davis' WebLog

IMHO C# can't be used for serious game development, at least not in it's current state. The .NET framework is too much of a memory-hog. A simple d3d app using C# quickly fills up 20-30MB of RAM, while a similar app using native C++ would only take up 1-2MBs of RAM.
Don't get me wrong though - C# is one of the best things that have happened to me in years ;)

There was a discussion about this on slashdot a couple of weeks back. It may be of interest to you to read the comments there ( some folks had done performance tests etc )

http://developers.slashdot.org/article.pl?sid=03/04/28/163219&mode=thread&tid=126&tid=127&tid=186&tid=156

Personally I dont think you could make Battlefield 1942 with dotnet but on mobile devices you could make some cool games.

I just think C# or even the .NET framework is still in the baby stage.

It M$ just cheating ppl to use it at the moment

I just think C# or even the .NET framework is still in the baby stage.

It M$ just cheating ppl to use it at the moment

You have no idea about .NET. How is it Microsofts way of making money? .NET is great yes a bit slower and takes a bit more memory up but its the way forward. Back up your agruments instead of posting *It M$ just cheating ppl to use it at the moment *

I know c# pretty well, and it has it's advantages. From what I have seen , it runs directx9 pretty fast. Go try some demos from the directx9 sdk for c# they run at the same fps.

However, optimizing c# can be hard. It does, suck the ram, but who cares about ram really when it costs 50$ for 256 megs?!

It could cut down on development time on some things. Such as instead of building your own game scripting language, why not just use c#.

With C# there's only about a 6% decrease in graphics performance as compared to C++ - this is according to Tom Miller(Microsoft's Managed DirectX developer). 6% is definately not noticeable at all...considering the amount of cpu speed we have nowadays. By using Managed DirectX, C# game programmers will be able to actually spend more time *developing* the game, rather than optimizing it. The time and headache saved with C# is much more valuable than 6% decrease of performance.

I heard that C# programs because they are compiled just-in-time they can take benefits from the platform where ther're running (using the extensions of the processor that the user has, like 3dnow, SSE, SSE2, etc.)

Do the same using C++ means differents code paths and that means more job, more hours, and more debugging.

Is that true?

I don't really know what I'm talking about, but what about garbage collection? I wouldn't want my game to suddenly hang while the collector did its thing. Would this even an issue?

First, lets start with the RAM thing.

C++ goes directly to the operating system for allocations/deallocations over 4k (Microsoft, Borland, Metrowkers, MingW, Watcom), forcing a ring 3 to ring 0 transition and forcing any MMX, SSE or 3DNow code to run a couple hundred clock cycles (worst case) of transition effort. This is less on more modern chips, but it is still a significant hit on Intel architecture.

But because C++ does this, what you see is that if the program makes a lot of small memory allocations, task manage and similar programs report it is using very little memory. If a C++ program is using close to all available system memory, the computer starts running very slowly. There are 3rd party libraries that have been seen to provide huge performance increases by eliminating some or all of the operating system calls, at the cost of a larger working set.

In .NET, the framework manages memory. Typically, you do not immediately destroy objects like you would in C++, and the programmer doesn't directly worry about memory useage. The framework slowly grows memory until a threshold is reached where it believes it needs to perform garbage collection, at which time memory is deallocated.

What this means is that you cannot assume that because a C++ or VB program that is at 256M memory useage, that a C# program at 256M has the same impact. As soon as any other process, .NET or not, tries to allocate memory, C# is going to scan it's entire pool of allocated memory, and then free some of it if possible.

Unless you are comparing a program where memory is allocated at the begining and then freed at the end between the two platforms, you are absolutely comparing apples and oranges.

It is possible, very possible in fact, to write C++ programs that operate this way. SQL Server, for example, uses as much system resources as it can, and frees resources if other applications ask for more memory. By doing this, it can operate much more quickly, because it's not having to go to the operating system over and over again.

If you look at modern games, most use some form of scripting language and/or virtual machine at their heart. Virtually every commercial game follows this design, because it makes it easier to maintain and test the game.

With .NET, it isn't necessary to use a scripting language to get these same benefits. You can use satallite assemblies, and because of how .NET handles interfaces, you can still insulate yourself from changes in the base code.

There have been dozens of articles written on how to insulate C++ interfaces from classes, and you'll find that all of them lack in one way or another. Most of them come out and say things like "if this happens or that happens, then you still break users."

If you look at interfaces in Java, COM or .NET, they make it much easier to isolate code.

If you look at the class loader in .NET, it's very easy to look for a "plug ins" or "mods" folder, and to investigate the modules in that folder for what classes they contain, and to identify and activate classes. It is possible to detect tampering with modules, and to use digital signatures to verify their origin, and to restrict feature set based on origin.

Anyway, I'm not saying C# is the way to go or that it isn't the way to go, I'm saying it's a matter of personal preference. But I am saying you cannot look at .NET framework example memory usage and draw any conclusions as to how a finished game's memory footprint would look by comparison, beause C# has very different allocation characteristics than C++.

I'm working with c# and directX for a while. Its a little slower and needs memory as previously said but the best benefit I see is that you can write somethin in a week than in C++ would take a lot more. Debugging is easyer and understand it more clearably.

I think C# is the way to go and M$ has a lot of smart employes and thrust me the XNA team knew why to use C# Express as the developing tool.