• Advertisement
Sign in to follow this  

[.net] .NET dev

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
As for learning the language, I'm a personal fan of Jesse Liberty's work in Programming C#. It takes a good pace with teaching the language and much of the object oriented design. Of course, don't rule out the option of learning VB.NET. Both C# and VB.NET are compiled into the same thing, so they're both just as fast. My preferance leans towards C#, though.

Once you're familiar with the language of your choice, my suggestion would be to check out SDL.NET. It provides an object oriented .NET interface to SDL. SDL.NET is nice as it's VERY easy to jump into. There's also a slowly growing community and the lead developer is very active with the users. A new version of it is coming out next week or so. [wink]

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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?

Quote:

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

Do you have a more detailed reference on that matter?.

You just have to consider how your object creation and releasing references affect garbage collection, but I think that's much easier than creating a custom memory manger in C++ and avoiding fragmentation etc!

Quote:

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 agree - I gathered that most games are graphics-bound rather than CPU bound, and the number of batches you submit is more important, against that C#'s interaction with DirectX will be made even more negligible.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Did I? Apologies if so.

I was just curious why you can see debug output for C++ but not for managed when they both use the same IDE.

I have DebugView now, but only my Debug.WriteLine[s] show up? Maybe I'm being nice to DirectX or you need to connect in kernel mode? I didn't have permission to do that, not being admin [cry].

Share this post


Link to post
Share on other sites
Sorry, I noticed the retail runtime was on...computer's been rebuilt recently...

Good luck!

Share this post


Link to post
Share on other sites
Quote:
Original post by RipTorn
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.

You can view DirectX debug output in Visual Studio's debugger if you enable "Unmanaged debugging" for managed projects (Project settings->Debugging).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by RipTorn
Normally, in .net, an object is simply reference counted before it is wiped from memory.

No, there's no reference counting involved. You might want to read Brian Harry's famous article about Resource Management to understand the difference: http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572

Share this post


Link to post
Share on other sites
All I can say is that I programm managed directX since the first version.
I also programm C++ and what I see is that the performance depend from the way you write code.
If you use shader and reduce to the minimum software operation is good as C++. If you pretend to create a physics engine in C# the lost of performance are a lot.
See my demo, all this demo are realized in C#.
http://xoomer.virgilio.it/robydx/material.htm

I'vent seen so much differences realizing the same demo in C++. The differences is that in less time I can realize the same thing.
I think that AA title (not AAA) can be done in managed directX with some C++ component. Then In my opinion some type of game like strategic, managerial or also where graphics is not to much important can be done in c#. Teorically also Half life 2 can be done in c# but need a more powerfull pc. Anyway if you can't use C# for game I think that is a very great language for tool.

Share this post


Link to post
Share on other sites
Your english is very bad so it was harder to understand you.. but still:
I've seen demos by MS and I think there is no muh difference between C++ and C# as far as rendering is concerned. Well, physics may be a whole different story.
Well, as I'm going to make a strategy game, I think C# will be just fine for me.

Thanks

Share this post


Link to post
Share on other sites
It's actually astounding if you compare it to my French! (A at GCSE) [grin]

I'll see if I can help just by rewriting a bit, but it is rather good! He managed to spell managerial!

Quote:
Original post by robydx
All I can say is that I programm managed directX since the first version.
I also programm C++ and what I see is that the performance depend from the way you write code.
If you use shader and reduce to the minimum software operation is good as C++. If you pretend to create a physics engine in C# the lost of performance are a lot.
See my demo, all this demo are realized in C#.
http://xoomer.virgilio.it/robydx/material.htm

All I can say is that I've programmed in managed DirectX since the first version.
I also program C++ and what I see is that performance depends on the way you write code.
If you use shaders and reduce software operations to a minimum, it's as good as C++.
If you intend to create a physics engine in C#, there is a big loss of performance.
See my demo, all programmed in C#.

Quote:

I'vent seen so much differences realizing the same demo in C++. The differences is that in less time I can realize the same thing.
I think that AA title (not AAA) can be done in managed directX with some C++ component. Then In my opinion some type of game like strategic, managerial or also where graphics is not to much important can be done in c#. Teorically also Half life 2 can be done in c# but need a more powerfull pc. Anyway if you can't use C# for game I think that is a very great language for tool.

Not sure what you're trying to say there, do you mean 'I haven't?' The difference is that I can do the same thing is less time.
I think that an AA title (not AAA) can be done in managed DirectX with some C++ components. Then in my opinion, some types of games like strategic, managerial or also where graphics are not so important can be done in C#. Theoretically, also Half Life 2 can be done in C# but would need a more powerful PC. Anyway, if you can't use C# for games I think it is a great language for tools.


I hope that helped,
Andrew

Share this post


Link to post
Share on other sites
Just to add on a bit myself, most games are graphics card bound rather that CPU so using managed for non-AAA games should be fine.

My game for one is pixel shader bound, but I have a GeForce FX 5200, which is reputed for poor pixel shader performance.
But it was the cheapest card supporting Shader Model 2.0 alright!

Share this post


Link to post
Share on other sites
Hehe, fine.
Well, managed seems notso slower than unmanaged. Today I've been testing and there is not much difference... some scenes are even faster :|... maybe I'm testing wrong stuff...

Share this post


Link to post
Share on other sites
Proper memory management is really the key to making a great C# application (Game wise or otherwise). Just because the memory gets released for you by the GC doesn't mean you don't have to take care about your allocations.

One of the biggest hits you can see is when the GC has to perform a non generation 0 collection, typically because you have temporary objects that have lived longer than they should. Finalizers can also slow things down here, as the finalization thread is a low priority one. If you don't need to finalize an object, don't provide one.

Ultimately, the difference between C# and C++ (or other unmanaged languages) comes down to the experience of the developer in either. A poor C++ application will be slow, just as a poor C# application will be slow. You should also realize that you aren't likely to be pushing the machine (even "AAA" titles don't do that, as they are usually bound by the CPU or the GPU (physics or graphics)). Get a profiler, there is a community one out there that is free for use. It can point you to methods, and objects (including allocations) that are costing you performance when you need to eek that extra little umph from your program.

Share this post


Link to post
Share on other sites
Quote:
Original post by RipTorn
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.


Like others have said, you can turn on unmanaged debugging and it'll output to the VS console. However, I've seen this make VS slow to a crawl when starting an application. Depending on your version of VS, there should be a utility included called dbmon.exe (C:\Program Files\Microsoft Visual Studio 2005\Common7\Tools\Bin\winnt\dbmon.exe is where it's located on my machine) and this will output unmanaged debugging to a console window and will be a little quicker about it.

Either way, it's all good.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement