Intergrating C++ into C#. Suggestions? Game Development.

  • Thread starter Thread starter Tom
  • Start date Start date
T

Tom

I have had a reoccurring issue with movement to C# and I was wondering
if any C# gurus can give me any suggestions to this problem. Lately I
have be running into companies with large c++ code repositories that
are interested in leveraging the power of C# development. However
Throwing away the c++ code is just not an option. Most of this is in
regards to the gaming industry where the base C++ code needs to be
run on something like a PlayStation, where you still want to be able
to use your code in Development tools on the PC. As you could imagine
these tools are VERY complex and would greatly benefit from the managed
environment.

If you boil it down here is really the problem. Let's say I have a c++
class Vehicle.

class Vehicle:public GameObject
{
public:
float m_speed;
float m_mass;
PropritaryStringType m_name;
}

This class is needed by the system at run time which CANNOT be managed
under any circumstances (I don't foresee a CLR interpreter for the
Playstation or GameCube any time soon). Also a lot of this code needs
to also run in tools like 3dSMax or Maya;

However when I am building content I would like to leverage the things
in C# like the PropertyGrid for automatic UI, and serialization. Not to
mention just getting it into C# so all the PC app development can
happen there.

In the past this was done with a MFC layer built on top of the game
code. In general you would build some proprietary Reflection system
into your c++ libraries and write some wild MFC UI Generator to
generate code. This has many downsides if you could imagine. These UI
generators are usually unstable and not as functional as the C# built
in systems, and usually take months to build and maintain.

One of the main issues that have to be solved is, only 1 point to
maintain the code. This code is being maintained by lot's of people
most of which will never even have VS.NET installed. i.e. maintaining
a parallel class hierarchy in c# is out of the question.

The objects members need to somehow be converted to Properties for
exposure to controls such as the PropertyGrid.

Being able to call methods on these objects is essential too. We are
not just pushing around data there is usually some sort of simulation
going on in these tools.

I have thought of many different ways to do this, but none are really
"Clean", and this stops many developers in this community for adopting
this technology, Imprisoning them in the world of MFC.
 
One of the main issues that have to be solved is, only 1 point to
maintain the code. This code is being maintained by lot's of people
most of which will never even have VS.NET installed. i.e. maintaining
a parallel class hierarchy in c# is out of the question.

The objects members need to somehow be converted to Properties for
exposure to controls such as the PropertyGrid.

Being able to call methods on these objects is essential too. We are
not just pushing around data there is usually some sort of simulation
going on in these tools.

I have thought of many different ways to do this, but none are really
"Clean", and this stops many developers in this community for adopting
this technology, Imprisoning them in the world of MFC.
Click to expand...

Have you considered a very thin MC++ wrapper around your C++ code?
 
The problem with this is that the C++ is changeing constantly and
rapidly and the people that are doing this work cannot be constanly
haveing to update a parallel class structure. Most of the time they
are not even famliar with PC development, let alone Managed C++.
Basically you are insuring that the MC++ layer will always be broken.
 
Tom said:
The problem with this is that the C++ is changeing constantly and
rapidly and the people that are doing this work cannot be constanly
haveing to update a parallel class structure. Most of the time they
are not even famliar with PC development, let alone Managed C++.
Basically you are insuring that the MC++ layer will always be broken.
Click to expand...

Then you are out of luck. C++ classes cannot be imported directly into C#,
you only have pinvoke(importing C methods), MC++, and COM interop, none of
which seem to fit your needs. I'm sorry but C++ is your best bet, you can
use MC++ directly, which allows you to use the .NET framework and write
*SOME* of your code in C#, but I suspect the lions share will have to be
written in C++.
 
Hi Tom,

Did you know that there is a newsgroup
microsoft.public.dotnet.languages.Csharp

There are a lot active who knows very much about C#.
(Although that is in this newsgroup as well)

Cor
 
Actually I posted the question there and got no response. Maybe it is
badly phrased. There is no particular reason to use C# over MC++, I
guest I really mean unmanaged to Managed. Using MC++ is fine but it
doesn't solve anything. I can bring an unmanaged class into a MC++
project and use it. But I would have to build a wrapper to do anything
usefull in .NET with it( i.e.. you can't even do any reflection on a
unmanaged class correct?). This is the step that I can't find a clean
solution for.

I'm seeing this all over the industry right now, and its a shame
because most game companies have just completely dismissed .NET
entirely. I'm pretty sure that even the next XBOX will not support
managed code. Which means that these companies will be doing MFC
development for at least another 5-6 years. Plus it will get harder
because more tools, source examples, 3rd part libs will be managed. Or
worst yet, maybe 3rd parties will also choose not to use .Net because
of this. I am afraid this fracture in the development community will
seriously hurt this industry, which is one the typically need to be on
the forfront of new technologies. Espically rapid development and
reuseability of UI code.
 
Actually I posted the question there and got no response. Maybe it is
badly phrased. There is no particular reason to use C# over MC++, I
guest I really mean unmanaged to Managed. Using MC++ is fine but it
doesn't solve anything. I can bring an unmanaged class into a MC++
project and use it. But I would have to build a wrapper to do anything
usefull in .NET with it( i.e.. you can't even do any reflection on a
unmanaged class correct?). This is the step that I can't find a clean
solution for.

I'm seeing this all over the industry right now, and its a shame
because most game companies have just completely dismissed .NET
entirely. I'm pretty sure that even the next XBOX will not support
managed code. Which means that these companies will be doing MFC
development for at least another 5-6 years. Plus it will get harder
because more tools, source examples, 3rd part libs will be managed. Or
worst yet, maybe 3rd parties will also choose not to use .Net because
of this. I am afraid this fracture in the development community will
seriously hurt this industry, which is one the typically need to be on
the forfront of new technologies. Espically rapid development and
reuseability of UI code.
 
Tom said:
Actually I posted the question there and got no response. Maybe it is
badly phrased. There is no particular reason to use C# over MC++, I
guest I really mean unmanaged to Managed. Using MC++ is fine but it
doesn't solve anything. I can bring an unmanaged class into a MC++
project and use it. But I would have to build a wrapper to do anything
usefull in .NET with it( i.e.. you can't even do any reflection on a
unmanaged class correct?). This is the step that I can't find a clean
solution for.
Click to expand...
No, you can't reflect over an unmanaged class. The integration story isn't
great, unfortunatly, for your purposes. However, althought you can't reflect
over classes, C++ class in-memory layouts are defined aren't they(atleast
for the compiler)? Have you considered writing a code generator that parses
your C++ header files and generates wrapper classes in MC++ or C# using
unsafe code? That would allow you to write your dev side tools in managed
code and still use the unmanaged classes as needed. It will take some work
but it should be possible to reuse the generation tool across multiple
projects and may be faster in the long run.
I'm seeing this all over the industry right now, and its a shame
because most game companies have just completely dismissed .NET
entirely. I'm pretty sure that even the next XBOX will not support
managed code. Which means that these companies will be doing MFC
development for at least another 5-6 years. Plus it will get harder
because more tools, source examples, 3rd part libs will be managed. Or
worst yet, maybe 3rd parties will also choose not to use .Net because
of this. I am afraid this fracture in the development community will
seriously hurt this industry, which is one the typically need to be on
the forfront of new technologies. Espically rapid development and
reuseability of UI code.
Click to expand...

As it stands, I don't htink managed code fits the platform gaming paradigm
very well. The GC alone causes some weird issues with delays, etc that may
anger gammers that wouldn't aggervate an office user, for example.
 
Why don't you compile your C++ as managed C++? This way you don't need
wrappers and you can access your C++ code directly from C#.
 
Please explain how this would work. I to have a class become visiable
to a c# application it had to have the GC Keyword on it. If this were
true that would be great because you could then reflect over the non
managed classes.
 
You do not have to deal with unmanaged code - you can simply recompile the
C++ code as Managed C++ code. Maybe you have to make some code changes, but
you should give it a try.
 
I have tried this, if you just comile normal C++ code in an assembly
it is not visible to C#. The classes to be GC to be visible. The whole
point is that I can't make code changes like making them GC classes
because then they wouldn't compile on the platform.
 
Back
Top