From C++ to C# and back again....

[Aaron]

I taught myself C++ a while back, but never got to
involved in actually writing applications with it. I
actually spent the last 6 years working for numerous
internet web firms as well as doing a plethora of
freelance web development work. Lately I started learning
c#. The idea is to stop using coldfusion and switch to
writing c# using asp.net. The advantage I believe is that
I can develop websites and software that reuse code and
are tied together in a Solution. This idea is very
exciting to me.

One of my other passions and interests is game
development. I've looked around at a lot of different
websites and have read over and over again that although
game development with c# is possible; it's just not
pratical, due to peformance issues brought on by
using .net, etc.

It is my understanding, however, that as a .net
application runs the called functions are compiled to
native code through the JIT compiler. Only functions that
are called are compiled, but once compiled, are not
recompiled through the life of the program. In addition to
this, the compiled code is more effecient since it is
compiled specifically for the system and processor it is
running on. And typically speaking, as a .net program
runs; it gets faster and faster (obviously hitting a
plateau when all code is compiled).

If this is the case, wouldn't a game programmed
using .net, have better performance? Isn't it possible to
still use pieces of assembly code or otherwise unsafe code
for specific functions where performance is key?

I was looking at the Mangaged C++ port of the Quake II
engine the other day and was reading that "Running Quake
II.NET in the timedemo test indicates the managed version
performs about 85% as fast as the native version."
(http://www.vertigosoftware.com/Quake2.htm). The didn't do
much explaination as to why the managed version was
slower.

C# itself doesn't seem like it was meant for game
programming. Am I right? What advantages does the C++
language have over C# that makes it better for game
programming (as far as syntax goes, not performance)?

Thank you.

 

[Guest]

Aaron,
You can use C# to develop games. It may be slightly slower than C++ (if
designed and implemented properly) be you will be much more productive.

Games developers are slow to move to C#. They already employ die hard C++
coders and there is a lot of snobbery regarding C#. Also C/C++ is used for
developing games for the consoles.

To start, try the following links.

Download the DirectX SDK
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/directx.asp

Managed DirectX discussio
http://msdn.microsoft.com/newsgroup...in32.programmer.directx.managed&lang=en&cr=US

Managed DirectX eposide of the .NET Show
http://msdn.microsoft.com/theshow/Episode037/default.asp

DirectX on MSD
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_directx.asp

Books on Managed Direct
http://www.amazon.com/exec/obidos/A...784/sr=2-1/ref=pd_ka_b_2_1/104-9919604-591356
http://www.amazon.com/exec/obidos/A...84/sr=2-2/ref=pd_ka_b_2_2/104-9919604-5913560

Good luck.
Phil.

 

[Aaron]

Very nice response. Thank you. I was most interested in
the suggested books (I'm very good with self-teaching
using books), and it would seem (after reading many
comments) that most of the DX9 books have issues with
compiling code because of the latest updates of DX9 from
Microsoft.

What about OpenGL programming with C#? Is OpenGL still a
qualified competitor of DirectX? HL2 uses DX9 right? And
D3 uses OpenGL right?

 

[paradox]

What about my question concerning assembly and unsafe code; I haven't
gotten to unsafe code in my c# book yet, can assembly code be used in a
c# application where peformance is imperative?

 

[Guest]

Aaron,
Personally, I've never looked at OpenGL. Suggest you try the following links.

http://www.opengl.org/
http://www.taoframework.com/
http://www.codeproject.com/csharp/csopengl.asp
http://sourceforge.net/project/showfiles.php?group_id=33241

Regards,
Phil.

 

[Sean Hederman]

No it can't.

From MSDN: "In unsafe code it is possible to declare and operate on
pointers, to perform conversions between pointers and integral types, to
take the address of variables, and so forth"

That's pretty much it I'm afraid. However you could easily write the parts
of your program that required assembler in managed C++, and call that
assembly from your C# code...

 

[paradox]

With the benefits of C# in mind, would it make sense to develop a game
mostly in C# and use managed and unmanaged c++ where necessary for
peformance? Would doing so effectively "cure" the performance issues
associated with using .NET for game programming?

To clarify my question. The purpose of using c# in such a case would be
for the ease of use provided by the syntax of the language and using
unmanaged code would be to avoid the cost of garbage collection and
have direct control over memory management. Are there enough advantages
in the syntax of the c# language to decide to write a game that uses it
in conjunction with c++ or would it just make more sense to soley use
c++?

As an alternative approach, would it be possible to develop the engine
in c++ and write the game code in c#? Thank you.

 

[John Puopolo]

Hi...

I think the former would work the best. In my experience (15 yrs)
developing software, one tenet has worked well for me... "make it work -
then make it work fast."

It is very difficult if near impossible to determine where your code is
spending its time -- so the only way to know where to optimize it to write
the code (in C#), profile it, then re-write the most-used routines in C/C++
or assembly to get the speed that you need.

You may find, however, that the managed code works just fine and that you do
not need to use unmanaged code at all.

John Puopolo

PS. I'd be interested in how this turns out -- post and let us know!

 

[thb]

Yes it can.

You can't add assembly code inside a C# project, since there is no
machine code in a .NET executable. However, you can create an external
DLL in asm, and call its functions from your managed C#.

This solution is very efficient if you don't switch too often from
managed C# to platform assembly. It ruins the supposed portability
advantages of C#, though.

 

[paradox]

Well most games are written in C or C++ and include pieces of assembly
and other code. Almost all of which are not platform independent. By
developing the majority of the project in c#, the components developed
in unmanaged c++ or platform assembly would be the only aspects of the
application that I would need to develop for each platform. This
correct?

I'm sure most games have other conventions they used to narrow down the
amount of code they need to rewrite for each platform; anyone have any
insight into what these conventions are? Thanks.

 

[Tad Marshall]

Your last sentence, that "You may find ... that the managed code works just
fine", is so true.

I just finished a program where I was doing processing on daily stock
prices, and had 30 years of data to process. I was afraid that this thing
would take days or weeks to do its job, but the managed code could run
through the entire 3.9 million records in about 15 minutes. Rewriting it
for greater speed would have been a waste of my time. Had it taken 15 hours
to do this work, I'd be rewriting it, but at 15 minutes per run it just
doesn't merit extra effort on my part.

It all depends on what you are doing. Managed .NET code is not necessarily
"slow" code relative to your needs, it all depends on what you are doing and
what your requirements are.

On a different part of the same project, I was writing code that hit the
same data over-and-over, and there was a lot of data to hit. In this case,
the key to speed was processing chunks of data that fit into the CPU cache.
When processing 30 MB of data, the speed was 8 loops per second, when
processing 600 KB of data the speed was 2000 loops per second. The extra
hit to read the data from disk in small chunks was trivial compared to the
speedup by getting all my data into the processor's 1 MB cache. A 20 hour
(projected) processing time was cut to 20 minutes. If you see actual
numbers and have a sense for what you are trying to do, you can sometimes
get improvements like this. The two hours of coding I did to rewrite my
algorithm were paid back in my first run of the data.

I'll add one more thought ... the very biggest returns to optimization come
from finding something that you don't actually have to do, and not doing it.
Making "uselessRepetitiveRoutine()" run at maximum speed is no where near as
effective as not calling it in the first place. Every now and then, this
tip makes all the difference.

Tad