Is C# part of the problem?

[Thee_oddball]

I remember reading this a while back...dont know if it applies though

Attempting to second-guess the garbage collector is generally a very bad idea. On Windows, the garbage collector is a generational one and can be relied upon to be pretty efficient. There are some noted exceptions to this general rule - the most common being the occurrence of a one-time event that you know for a fact will have caused a lot of old objects to die - once objects are promoted to Gen2 (the longest lived) they tend to hang around.

In the case you mention, you sound as though you are generating a number of short-lived objects - these will result in Gen0 collections. These happen relatively often anyway, and are the most efficient. You could avoid them by having a reusable pool of objects, if you prefer, but it is best to ascertain for certain if GC is a performance problem before taking such action - the CLR profiler is the tool for doing this.

It should be noted that the garbage collector is different on different .NET frameworks - on the compact framework (which runs on the Xbox 360 and on mobile platforms) it is a non-generational GC and as such you must be much more careful about what garbage your program generates.

[mazex]

From what I understand they use C# for the GUI and the scripting, just like IL2 used Java for the GUI... Most games use a more user friendly language for the scripting like Python (which is rather confusing in a way though ), the thing is that it comes without saying that the scripting part has to be JIT compiled

I'm pretty sure the game itself is coded in C++

Well - my oh my, at this point to not look silly I loaded Reflector to just verify that the core dll:s where C++ dll:s and not .NET and to my amazement the majority are really .NET assemblies, with a small bunch like the SpeedTree dll:s etc written in C++. Hmm, writing the core of a game like this in .NET feels very weird - I actually never thought of it as I was so sure that it was only the GUI and Scripting which felt OK...

A view in reflector of the core.dll that I thought was a C++ dll below... The "WLandscape" class in the image sure is a part of the render code that is in .NET as you can see... Or is it maybe just for the map editor? Nah, no need for "renderSunGlare" there?

coredll.jpg

EDIT: Interesting looking at the methods... Like cHQ_forestHeightHere(float x, float y)... Could be used to see if you should crash into a tree without actually checking the 3D tree object itself? And then there are a bunch of unmanaged types returned so there sure is interop going on (naturally)... Needs some more digging on what is done in C++ and what is done in .NET. I really don't understand why someone would come up with the idea to write a game like this in .NET. For an Indie game with no real preformance bottlenecks like Magica - sure. But this?

[WTE_Galway]

Also remember no garbage collector can stop resource leaks if the code is badly structured and leaves things open that are no longer needed. The garbage collector will just assume its left open for a reason and leave well enough alone.

[Thee_oddball]

Originally Posted by WTE_Galway

Also remember no garbage collector can stop resource leaks if the code is badly structured and leaves things open that are no longer needed. The garbage collector will just assume its left open for a reason and leave well enough alone.

so your saying that over a period of time alot of "stuff" is winding up in gen2?

[Thee_oddball]

Originally Posted by mazex

From what I understand they use C# for the GUI and the scripting, just like IL2 used Java for the GUI... Most games use a more user friendly language for the scripting like Python (which is rather confusing in a way though ), the thing is that it comes without saying that the scripting part has to be JIT compiled

I'm pretty sure the game itself is coded in C++

Well - my oh my, at this point to not look silly I loaded Reflector to just verify that the core dll:s where C++ dll:s and not .NET and to my amazement the majority are really .NET assemblies, with a small bunch like the SpeedTree dll:s etc written in C++. Hmm, writing the core of a game like this in .NET feels very weird - I actually never thought of it as I was so sure that it was only the GUI and Scripting which felt OK...

A view in reflector of the core.dll that I thought was a C++ dll below... The "WLandscape" class in the image sure is a part of the render code that is in .NET as you can see... Or is it maybe just for the map editor? Nah, no need for "renderSunGlare" there?

Attachment 8913

EDIT: Interesting looking at the methods... Like cHQ_forestHeightHere(float x, float y)... Could be used to see if you should crash into a tree without actually checking the 3D tree object itself? And then there are a bunch of unmanaged types returned so there sure is interop going on (naturally)... Needs some more digging on what is done in C++ and what is done in .NET. I really don't understand why someone would come up with the idea to write a game like this in .NET. For an Indie game with no real preformance bottlenecks like Magica - sure. But this?

get it to market faster?, use smaller team? or both. you think this maybe the reason for the micro stutters and leak?

[MadBlaster]

Originally Posted by Thee_oddball

get it to market faster?, use smaller team? or both. you think this maybe the reason for the micro stutters and leak?

This is my fear. I wish I could offer more insight, but I just started reading about programming since January and I never read a C# book. So very newbie. Interesting responses so far.

[Skoshi Tiger]

Didn't the original Il2 Series use Java as it's scripting language? (Though not available to mission designers)

I would have thought that C# would have been a bit more efficient. (Could be wrong though!)