2

I'm currently working on a Game project, so I'm developing my editor in C# because it would take alot of time to do it in C++ so for efficiency I use C# as the editors primary language, to get results quick.

However, is it possible to create a Game Editor in C# that creates C# objects that can be read by C++, or a Game Editor in C# that creates C++ objects that can be used in C++?

This is because C# is a RAD environment so it's quick to develop windows application, but C++/DirectX is probably the best environment for a game.

Is there any way to combine the two since they're both part of the .NET Framework?

Deukalion
  • 2,516
  • 9
  • 32
  • 50
  • Are you looking for [COM objects](http://www.csharphelp.com/2006/08/building-com-objects-in-c/)? – huysentruitw Nov 12 '12 at 14:55
  • 2
    Tell me the reasons why your engine should be in C++. Normal C++ is not part of the .NET Framework. If you refer to managed C++, then it's the same as C# but with the C++ syntax. – LightStriker Nov 12 '12 at 14:55
  • I guess you don't really need to pass objects directly from your editor to your game engine. Instead, you probably want to save your objects created in your editor on file(s), and then be able to read the objects from your C++ code. For that, JSON or XML should be useful. – piokuc Nov 12 '12 at 15:03
  • Note: C++ is not a part of the .NET framework. – Justin Self Nov 12 '12 at 15:05
  • Okay. There's a part of C++ that's part of the .NET Framework, as LightStriker said (Managed C++). But is there a way to do this, or something similiar. You get the idea of my question, just asking about the possibility and perhaps some reference. I'm gonna look up COM Objects now. – Deukalion Nov 12 '12 at 15:08
  • @Deukalion: You got it wrong. C++ and Managed C++ is two different language that doesn't speak to each other and cannot be mixed, the same way C# and C++ cannot talk. Managed C++ is the same as C#. – LightStriker Nov 12 '12 at 15:11
  • @LightStriker: Your last comment is totally wrong. C++ and C++/CLI mix just fine, using "C++ interop". Even C++ and C# mix pretty well, using p/invoke or COM interop. – Ben Voigt Nov 12 '12 at 15:12
  • @piokuc: You had a great observation, then ruined it by suggesting JSON and XML. Why would you turn to some of the most resource intensive and difficult to parse formats when you care about performance? – Ben Voigt Nov 12 '12 at 15:14
  • @BenVoigt: You got "pretty well" a bit wrong here. In the case of the development of a video game "pretty well" is not good enough. They mix well when what you call is not gonna change. In a game, it keeps changing all the time and you need to update your definitions on both sides all the time. – LightStriker Nov 12 '12 at 15:16
  • @BenVoigt these are just examples. What other formats are more suitable? – piokuc Nov 12 '12 at 15:16
  • @LightStriker: You have obviously never used C++/CLI, since you keep talking about "update your definitions on both sides". You don't update any definition, you just `#include ` and go. That's one of the biggest strengths of C++ interop compared to p/invoke. COM interop also pulls in the definition automatically. – Ben Voigt Nov 12 '12 at 15:18
  • @piokuc: Lots of options, but the [Google Protocol Buffers](https://developers.google.com/protocol-buffers/) format is a great example. The documentation specifically describes when design decisions were made to favor performance. – Ben Voigt Nov 12 '12 at 15:22
  • 1
    @BenVoigt OK, GPB sounds good, but the performance requirement may be over exaggerated. I imagine you typically don't define gazillions of objects in a game editor, but few dozens or maybe few hundreds of objects which define an initial state of a game level, and you need to load them once. A text based format has the advantage of being human readable, and makes it easier to debug the editor while you develop it. – piokuc Nov 12 '12 at 15:31
  • @Deukalion The reason i said C++ is not apart of the .NET framework is because its not... Your question "Is there any way to combine the two since they're both part of the .NET Framework?" hints at a possibility that you either mistyped or didn't quite know that. Ergo, I made a comment. C++/CLI != C++... – Justin Self Nov 12 '12 at 15:34
  • @piokuc: Most games I play have a noticeable loading time. I would be quite annoyed if that time increased by a factor of 10. Or conversely (if XML formats are the norm that I'm seeing), I would be much happier with a game that improved loading times by a factor of 10 over the competition. – Ben Voigt Nov 12 '12 at 15:42

3 Answers3

2

In the past I successfully used C++/Cli to create C++ object from C#. Basically you can create a C++ (managed) library that loads/creates c/c++(unmanaged) objects. Than you can use this managed library from a managed (c#/vb) library/application. Be aware of the following:

  • C++/cli can be only built for a specific platform (x86/x64) so you will need to build your managed editor accordingly
  • Visual studio 2012 doesn't support intellisense for C++/cli as long as Microsoft doesn't like this scenario so much

Also COM and p/invoke are viable alternatives.

gigi
  • 796
  • 9
  • 21
1

Communication between C# and C++ (Or between any managed and unmanaged language) is a pain in the ass and unless you have very very good reasons to use, should be avoided.

For communication, you can use pipes, WCF, COM, P/Invoke and some other custom commercial option. You can search the net for that. In an engine I worked on, we use an anonymous MemoryStream shared by multiple processes.

But what always come back as a problem, is that for any structural change in C++, you need to reflect those in C#. Like if you change the param a method takes, or the definition of a struct. There is some solution to automatically "mold" your C# to always be up to date with the C++, but they are expensive and heavy to implement.

Now, why you shouldn't bother! True, you won't find high-end commercial engine in something else than C++. Unreal? C++. Source? C++. Crysis? C++. Because C++ gives the performance that any managed language cannot offer. It also allow direct control of the memory and micro control of how the objects are created and erased.

So, why you shouldn't care? Because, unless your plan to ship a triple A game the size or range of Assassin's Creed, Half-Life or Skyrim, C# under the XNA Framework will give plenty of space and performance. Far more than you should ever need. If you actually have performance problem, good chance the managed language is not the problem and there should still be plenty of optim in your code left to be done. Chance is that if you have performance problem in C#, you would have them in C++ too.

XNA also give the ability to ship on Windows, Xbox and the different Microsoft portable devices. Beside, taking DirectX limit you to those platform anyway.

LightStriker
  • 19,738
  • 3
  • 23
  • 27
  • 1
    C++/CLI fixes all of this. It recognizes .NET types, and it recognizes C++ types. It uses the native description of each (.NET metadata and C++ header files). There's no extra work to keep both environments in sync. Heck, even "Managed Extensions for C++" (old, buggy, now unsupported so don't use it) handled this problem. – Ben Voigt Nov 12 '12 at 15:15
  • @BenVoigt: So, you tell me, I put a unmanaged C++ solution in the same project as a managed C++ solution. In managed C++, I can create unmanaged C++ object directly, with any need of translation? – LightStriker Nov 12 '12 at 15:19
  • Yes. All you do is `#include` the header file for the unmanaged C++ type, and link with the static library. Just like you would do with another unmanaged C++ project. – Ben Voigt Nov 12 '12 at 15:23
  • @BenVoigt: I keep googling, and it always comes back to the fact that you need a wrapper around your unmanaged objects and to marshal stuff around. Obviously not getting the documentation you do... Mind posting some link towards a full tutorial? Like this: http://stackoverflow.com/questions/10660214/mixing-managed-unmanaged-c – LightStriker Nov 12 '12 at 15:30
  • Wrappers come in when you want to use unmanaged C++ objects from C#. Then you can write p/invoke declarations (for flat APIs that don't use objects) or C++/CLI wrappers which can handle a rich object model. But this only applies when everything is already done in unmanaged code. – Ben Voigt Nov 12 '12 at 15:39
  • In the scenario under discussion here, you would write the C#-usable object model *once*, using C++/CLI `ref class` and `value class` types. The implementations of those can call all the highly-optimized unmanaged helper functions they want. No duplication. No wrappers needed, unless for some reason the C# code needed direct access to the helper functions. – Ben Voigt Nov 12 '12 at 15:40
  • @BenVoigt: The idea is to build an editor. If you cannot edit and call method from the unmanaged object, there is no point in creating those objects in the first place. You have to be able to edit every fields contained in those objects for the editor to work. – LightStriker Nov 12 '12 at 15:42
  • But you don't need to access the z-order sorting functions, or hash table search functions. A managed object model with optimized native implementation is very viable. – Ben Voigt Nov 12 '12 at 15:45
  • Perhaps ya'll should finish this in a chat? – Justin Self Nov 12 '12 at 15:46
0

Is it possible to create C++ objects from C#?

Not directly. For starters, I don't think you can call a constructor using P/Invoke; you will always have to export a special "constructor wrapper", e.g.:

extern "C" {
    EXPORT_API YourClass* YourClassInstanceFactory()
    {
        return new YourClass();
    }
}

For subsequent thiscalls , you probably need to keep track of all the adorned names which are subject to change every time you compile your library.

You could create a wrapper library in C++ that extern C helper functions to be Platform Invoked through C# but then again, not really sure of the overhead this might add and I presume your concern is performance.

Another solution could be to create a C++/CLI (CLR Class Library) wrapper library that can be directly referenced in C#. The advantage of this approach is that you may reference native libraries the same way you would in a regular C++ project.

Anzurio
  • 16,780
  • 3
  • 39
  • 49