As far as I've read, .NET games in C# and DX9 are not slower than their C++ unmanaged counterparts. As that was my main concern, I'm ready to move on. Now, I would like to know is it really good to choose .NET and are there any problems you encountered that make .NET gamedev not such a good choice. I would like to also know of a good book title that could lead me into .NET gamedev and that features a complete guide, not only specific tasks, but a complete solution to graphics rendering. To make it easier for you, my idea was to make a turn based strategy game like civ, but with 3d objects on 2d maps and battles in a full 3D. I don't need ultra fancy soft shadows etc., just plain simple stuff.

There are two drawbacks to C# gamedev: first, not all users have the .NET Framework installed on their machines nor are they willing to download it. In all reality, this may not be a big deal because finishing a game is more important than distributing a game. Second, there are a lot of libraries out there that are useful for gamedev (though not necessarily gamedev-specific) that will be tedious to use right away in a Managed context. Not impossible to use, just tedious, particularly if you're fresh to Managed programming.

In reality, neither one of these issues are showstoppers for the majority of folks. For the type of game you want to do, performance will be a non-issue when it comes to C#'s interaction with DirectX. And if you write your C# code correctly, the compiler will make code that's basically as fast as the C++ equivalent (particularly when you consider how much easier the C# code is to write/maintain/debug!).

Good luck!

there are a bunch of things you need to know.

biggest is that when using .net, you will not see unmanaged DirectX debug information output to the console (which you do see in C++). So you will need a 3rd party debug viewing tool, such as DebugView.

Next, you 'don't need' to worry about memory managment in .net. This is only partially true.
Normally, in .net, an object is simply reference counted before it is wiped from memory. But there are cases where a big section of your application suddenly is no longer being used, but each part of that section is still tied into the section in some way. This situation is *very* difficult for the garbage collector to sort out, because it absolutly has to make *sure* that nothing in that now disguarded section is still being referenced by the active portion of your application. This is very tricky to prevent, but when this type of garbage collection happens your frame rate can take a massive hit. This isn't a bug in .net, it's simply an extremly difficult problem.

also as of now you are pretty much going to be windows only, especially if you use .net 2.0 (which you absolutly should use).

Also remember that in .net, chances are what you are trying to do is already done somewhere (if it's a realitivly simple non-game related operation).

Thats probably enough to start with :-)

Quote:My preferance leans towards C#, though.

C# is much more powerfull. It's not just about compilation to MSIL.
-

Quote:not all users have the .NET Framework installed on their machines

Not all had DirectX ;) Today, it's just too easy to download and install 23mb..;)

Quote:also as of now you are pretty much going to be windows only

Soon 2.0 is going to get on Linux. Anyway, 90% of games is played on Windows, after all..

Quote:Also remember that in .net, chances are what you are trying to do is already done somewhere (if it's a realitivly simple non-game related operation).

That is quite desirable, as really, .NET has some cool classes for such stuff.

-

Quote:biggest is that when using .net, you will not see unmanaged DirectX debug information output to the console (which you do see in C++). So you will need a 3rd party debug viewing tool, such as DebugView.

Hmm. Interesting..

Quote:...This isn't a bug in .net, it's simply an extremly difficult problem.

Do you have a more detaile reference on that matter?

Quote:In reality, neither one of these issues are showstoppers for the majority of folks. For the type of game you want to do, performance will be a non-issue when it comes to C#'s interaction with DirectX. And if you write your C# code correctly, the compiler will make code that's basically as fast as the C++ equivalent (particularly when you consider how much easier the C# code is to write/maintain/debug!).

I saw demos, and it seems like there is no performance drawback in any of possible game types..

Quote:Original post by DrGUI

Quote:Original post by monolithx

Quote:biggest is that when using .net, you will not see unmanaged DirectX debug information output to the console (which you do see in C++). So you will need a 3rd party debug viewing tool, such as DebugView.

Why doesn't VS get this output? Perhaps enabling unmanaged debugging might help?

You missquoted :p

I don't know. I'm not even a noob yet in managed dx. Just gettin' started;)