Jump to content
  • Advertisement
Sign in to follow this  
monolithx

[.net] .NET dev

This topic is 4667 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!