Jump to content
  • Advertisement
Sign in to follow this  
Scared Eye

C# Simple, but good enough?

This topic is 5052 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

I would like to know if C# is any good for game development. I heard that it is alot slower than C\C++. I have also heard that in some cases(I\O) it is faster than C\C++, is this true? Managed DirectX is suposed to give me the performance of C++ to C# in DirectX apps. If so then there is no reason to choose C++ over C#. I would also like to know any good links to C#/Managed DirectX resources. THanks for your time. S-Eye

Share this post


Link to post
Share on other sites
Advertisement
C# is perfectly good for game development. Typically its performance is about the same as that of similar C++ code, but it may be either faster or slower for specific applications depending on usage.

I'm afraid I don't know much about Managed DirectX, but I believe its primary advantage is in ease of development and debugging. I would expect its performance to be similar to unmanaged DirectX.

Share this post


Link to post
Share on other sites
it's not "a lot" slower than C\C++, however it is marginally slower in execution time.
C# is "faster" than C++ in application developement time.

Consider this, C# is easier to learn than C\C++. It is also adequate for all but the most complex games (I'm talking somethink like Morrowind with even better graphics). Do you think that you will EVER create a game of that calliber, on your own (also consider that these types of games are created by large teams of developers over the course of a few years).

Basically, C# should be more than adequate for your needs.

Managed DirectX is negligibly slower than DX in C++, it is a thin wrapper around the DX API, so it does add some overhead, however the true overhead comes from C# being a managed language, whereas C++ is not (however, it can be a managed language, in which case DirectX applications in C# and C++ will run at the same speed).

Share this post


Link to post
Share on other sites
Download the demo from this site http://arenawars.krawall.de/com/
its a commercial game writen in C#, it looks good and is a lot fun, and it runs great.

Check out this book: Managed DirectX 9 by Tom Miller. its the closest thing to a C# & Managed DX bible ther is.

There is a lot of dispute with very little hard figures about C# speed vs C++ speed.
With perfect coding on both sides people say you will see a +2%-5% speed benefit in C++ though i hear the ogre 3D enige runs faster in C#.
THOUGH thats assuming perfect code, C# being managed allows you to avoid many of the pitfalls of programming with C++. Meaning if your not a pro your code will probably be tidier and faster in C#.

I cant swear to all that advice being the gospel truth but it is what i was told by almost every body when i was thinking of getting started in C# game development. (which i find SOOOO much easier to get decent results with than C++).

Share this post


Link to post
Share on other sites
My problem with people saying that C# is slower is that, has it actually been slow for them? It's kinda trendy on these forms to criticize C# and Java for being too slow but I rarely see anyone doing something that would really need that speed difference. I recall that Quake 2 was rewritten in C# by some programming crew and it ran perfectly fine. And C# could obviously be used for more powerful games than Quake 2. Yet very few people could actually program something at the level of Quake 2.

I guess I'm just trying to say that if you like C#, go with it. Until you're ready to program something like the latest games, do you really need the speed of C++? Not to mention, C# is a great way to learn DirectX.

Drunken Hyena has some good C# tutorials (look for his Direct3D 9 Tutorials)

The ZBuffer will point you to some great sources.

Here you'll find a tutorial on setting up C# and drawing a 3D landscape.

And most importantly, check out the Documentation folder in your DirectX SDK directory. It has a 6 part tutorial on using managed directx in C# as well as some awesome code samples.

Best of luck!

Share this post


Link to post
Share on other sites
Thank you guys for such fast replies!

I would be even more greatful if you guys could recomend some texts on 3d physics and math for C#. I have found alot of them which are only for C\C++.
Thanks again!

S-Eye



Share this post


Link to post
Share on other sites
Managed DirectX 9 Kick Start Everyone loves this one.

Also, it wouldn't hurt to read through the SDK tutorials and then pick up one of those C++ books. I find I learn more when I program in a language other than the one the book uses because it forces me to learn instead of just copying what the author did.

Share this post


Link to post
Share on other sites
Here aresome links:

Millers Blog:
http://blogs.msdn.com/tmiller/

Video Interview with miller RE his book:
http://msdn.microsoft.com/theshow/Episode037/default.asp

MSDN DX site
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_directx.asp

Also avoid this book i found it very badly put together:
Introduction to 3d Game Engine Design Using Directx 9 and C#
None of the source code will actualy compile (its very out dated)

If you learn the maths and phisics and also know the basics of the language your porgramming in its fairly simple to get a program to perform a mathmatical equasion.

I have this book:
http://www.amazon.co.uk/exec/obidos/ASIN/0201619210/qid=1103221733/sr=1-8/ref=sr_1_10_8/026-5408689-6618865
and although its not C# or even DX it explains the concepts of 3D so well that if you know the language and gfx api you can apply a lot of this books teachings on 3D to anything.

Share this post


Link to post
Share on other sites
I've popped open the disassembly window in VS2003 when running a C# program to see what the actual code executing on the processor looked like. For the half-hour or so that I messed around testing basic code differences in C# and C++, it seemed like C#'s JITted machine language is more-or-less the same type of stuff that the C++ compiler spits out...

the first major differences I noticed were in collections:

Arrays will perform bounds checking on EVERY item-fetch/store operation. not just when you use the "System.Array" class, but even when you use int[] or float[]. Then I realized the compiler is actually using the System.Array class when you declare an array like that, and essentially using the Array.this[] indexer.

The thing you have to understand is that everything you use in C# (down to the basic types like int, float, and the arrays) are represented by classes/value-types - some of the simple operations that you're used to (like the array dereference) will perform extra checking operations (like bounds checking, overflow checking, etc). You can avoid *some* checks (like overflow checking) by using the 'unchecked' keyword (or turning checking off in the project preferences). 'unchecked' doesn't affect arrays, though.

If you have time-critical code related to array lookups, you can (and possibly should) pin the array and access the contents using unsafe pointer stuff. I use this a lot when I want to manually set the pixel colors across an entire bitmap, and I can say that the performance is QUITE adaquate (it's the same performance I can expect from the same operation in C++).

foreach: for ArrayList, at least, your basic 'foreach' loop doesn't cache the size of the collection - it looks it up once per loop iteration.

Get/set properties: The compiler will expand the assembly for these like inlines if it decides that it would be better, but AFAIK (just like inline) you cannot force the expansion.

managed pointers: Ok, managed pointers will probably be the main bottleneck that you can never get rid of. The Garbage Collector specs dictate that any managed object can be moved around in the heap BY A SEPARATE THREAD - this means that you can never be sure of the actual address of an object (unless you pin it). This means your functions are passing around a pointer 'wrapper' of sorts. I haven't gotten down to the level of figuring out how much overhead they have for thread-safe operations, but hopefully it's not too much.

C# Type Reflection: the "is" and "as" operators function by comparing a type-handle-integer to the type-handle stored by whatever managed object you're trying to look up. This is the fastest method that I know of for looking up "what type is this?" info. I haven't checked out the guts of C++ RTTI to see how it compares.

literal conversion: I haven't checked C#, but there is often a hidden issue when you initialize floating-point variables. Say you do "float f = 1.0;" "1.0" is recognized by a lot of compilers as a double (not sure about C#, but most C++ compilers do this) - often, the optimizer fixes this, but many times the generated code will have a double-to-single conversion operation. The standard way to avoid this is to write "float f = 1.0f;" instead. C# *will* warn you about every single time where one of these conversions happens.

I'll probably be testing the JITted C# code some more as Visual C# 2005 comes out... they mentioned doing some optimization of some of the framework classes, so maybe there will be some JITter optimization, too.

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!