Official Fulqrum Publishing forum - Is C# part of the problem?

Official Fulqrum Publishing forum (http://forum.fulqrumpublishing.com/index.php)

- Pilot's Lounge (http://forum.fulqrumpublishing.com/forumdisplay.php?f=205)

- - Is C# part of the problem? (http://forum.fulqrumpublishing.com/showthread.php?t=30774)

Good read Mazex. Maybe Luthier knows this now.:-P

Quote:

Originally Posted by mazex (Post 403582)

Well, I started working as a C++ developer in the mid 90:ies and switched to C# in 2006 for those reasons so I agree, if it would have been a business application... C# is an easier language to work with in general and If you have a team that includes junior developers doing businesses applications there is no debate on what to choose, the benefits of the .NET framework for business apps is a real boost too, as you have base classes for most everyday needs like talking to web services, mail servers, mq servers etc..

For gaming though it's a different story... The benefits of all those base classes in the .NET framework are really minor as most of the code is maths anyway, and one can assume that game developers know how to allocate and deallocate memory as you can't just let the framework do your cleanup if you use millions of objects that is rare in a business app. You just can't have a GC collect when doing 100 fps. And you really need 100% performance and then C# is not the best language... Sure there are many claims lately that a well written C# program is just some percent slower than C++, the problem is that a sloppy C# program is not. You leave too much in the hands of the runtime, and when tuning performance you are not in full control. And then you have the problem that most of the external libraries that you use in a game are written in C++ (like directx and speedtree) so to use them you get what is called Interop, which is when you go from managed code to unmanaged code, where managed code is the C# code where the memory is managed by the. NET runtime as opposed to the unmanaged code written in C++. And interop costs peformance when you context switch between them. It works a lot better today than in the first versions of .NET and I remember a project where we tried to use a mixed C++ / C# in 2005 where we had to ditch it and go back to unmanaged code as the memory demand increased and we lost too much performance... And in the end it was not that much faster to use C# as it was a team of experienced C++ developers.

There are many games popping up these days written in C#, mainly by small indie teams using some generic 3D engine like Unity3D, but all the bleeding edge games are written in C++... And I don't see that changing as you loose control and performance to be able to have an easier programming language...

/mazex

nice post maz thnx for the info now i know what interop means :) I have a question i think you would know the answer to...if i started writing a game using OPENGL but half way through decided to with just directx how difficult would that switch over be?

Quote:

Originally Posted by Thee_oddball (Post 403746)

Well, I'm not a game developer even though I once tried but got tired when the collision and response made me realize how much work it is. As the actual render code where the objects are actually drawn to the screen is not THAT big part of the code base I guess it would not be that hard if you are not dependent on features that don't overlap. Most of the time OpenGL and DirectX follow each other functionality wise so I guess it would not be that hard - many games ten years ago had it, like IL2 of course ;) But as I've only done DirectX on an amateur level I'm just guessing...

This is my only game attempt from 2005 so I'm really not in a position to criticize CloD ;) It had awesome fps though ;) 500+ if I remember it right... It's a lot easier talking than doing it yourself ;)

Hmmm. Are you speaking in code???:confused:

Quote:

Originally Posted by Thee_oddball (Post 403746)

nice post maz thnx for the info now i know what interop means :) I have a question i think you would know the answer to...if i started writing a game using C# but half way through decided to with just C++ how difficult would that switch over be?

Sorry, couldn't resist.:grin:

Quote:

Originally Posted by mazex (Post 403766)

nice pic...thats better than %99 of us will ever do , you might get a kick out of this..it was a flight sim for Linux that was made between 2002 to 2004 called Gl-117 http://www.heptargon.de/gl-117/gl-117.html.

and if you have any desire to do any kind of programming for a flight sim try this one..its open source . http://www.flightgear.org/

S!

Quote:

Originally Posted by MadBlaster (Post 403772)

Hmmm. Are you speaking in code???:confused:

Sorry, couldn't resist.:grin:

from what I have read the game started out using OPENGL but later switched to DirectX :)

Quote:

Originally Posted by Thee_oddball (Post 403804)

Thanks for the links, hadn't heard of GI-117 before but I've had some fun with flightgear!

The hobby project I'm thinking of now is actually doing a small game in Unity3D as I realized that my last project from scratch was way too much work... And with kids and challenging daytime work as a development manager there is little time left. The dilemma is that at work I haven't done any real programming the last five years so I need my fix ;) For a therapeutic project like that C# will be perfect... Just the logic and no plumbing!

/mazex

Maze i found a nice read you might enjoy

Quote:

With Microsoft's introduction of the .NET platform and languages, including its bias towards distributed application components, performance analysis and performance tuning have become substantially more important for today's development efforts. Individual assemblies and Web services that seem to offer adequate performance when unit tested perform unacceptably when integrated as a single application.

One of the biggest, yet largely unexplored, areas of .NET performance concerns the so-called "interop" – the interoperation of managed and unmanaged code in the same application. In most cases, this involves new .NET code calling native code components. However, it's also possible for native applications to call .NET components, although by its nature this is likely to be much less popular.

At this point, many developers don't understand the performance implications of interop. Moreover, they aren't necessarily even cognisant of when their application is performing interop, and what they can do to resolve such problems. In some cases, interop is performed by the .NET Framework, and most developers think it can't be helped. For example, Figure 1 shows the negative performance implications of a line of code that calls into native code indirectly through its children.

heres the whole article http://www.developerfusion.com/artic...t-performance/

These points stand out.

"Now here's the rub. Marshalling is computationally expensive, and the more data you move back and forth, the more expensive it becomes. Marshalling data structures one way can add as much as 3,000 instructions to your processing time for complex data. "

"By investing a little time early in the development phase, you can ensure that you made the right performance choice and not have to go back and make substantial changes after you have a working application. "

Can we call CLoD a case study at this point?:-P

Jmho, the author comes across bias to managed mode programming. It's a good article though. Hopefully CLoD coders have access to the tool(s) the author speaks about to optimize the interop.

Memory leaks can occur in any language, no matter if a garbage collector is present or not. It's comes down to following good coding practices, it's especially important when making interop calls.

For me I have no doubt that CloD is written in C# due to early error messages people were posting after release. Also the only official Microsoft "Direct X" API that operates on .NET is XNA, however this is capped at DX9 so you can safely say that they CloD is making calls to the un-managed version of Direct X which is the current main stream API of choice.

Maz is right, interop calls are taxing and I wouldn't be surprised it that has been the main cause of all the issues because I get the "feeling" that this style of programming for a game is still in it's pioneering days.