C# Tools for a C++ Engine
Author
I've been meaning to learn C#, and quite a few people recommend it for tools, but I've always decided I'd rather make tools in C++. Yes, I'm comfortable in C++ (and my C# exposure can be counted in hours), but that's never been my decision maker. I've never encountered a single tool that wouldn't need some piece of functionality from my engine, which is written in C++.
If I want to make a simple model viewer, I'll need to load the model from my custom format, and all the functionality is written in C++. Once loaded, it still needs to be rendered and animated, again, C++.
How does everyone solve this problem? Yes, I could re-write the libraries in C#, but I don't think the time spent maintaining two code-bases would benefit me compared to just making the tool directly in C++. I've read that you can use P/Invoke and load functions out of DLLs, but with that approach you're still looking at only needing to interact with a small portion of your engine, and that also assumes you're using DLLs, which I can't imagine everyone does.
I've also heard you can do a managed wrapper in C++/CLI, and then call the managed code from C#, but I'm not sure how practical that is. On a large project, like a level editor, you need to interact with many pieces of your native C++ engine, and none of these options seem to be a good solution over simply creating a C++ level editor or an in-game level editor and using the existing infrastructure.
Can someone tell me what I'm missing? I would love to make some GUI tools in C# if I can figure out an acceptable way of doing so.
Your point is valid, having your tools and engine and other stuff all written in the same language allows to share a lot of code, that's a benefit.
It comes at the cost of more dependencies though (changing one thing may have impacts on many other things)
It also forces you to have a very modular design, which is usually a good thing if done right, but that's not easy.
C# provides a ton of things, which is a big benefit over C++. BTW, have you considered writing your engine and your tools using C#?
If you're considering C# for GUI in particular, then it's possible for you to make all your C++ tools command line driven, and create a GUI in C# to act just as a front end (if you know perforce, think of p4 vs. p4v, for example)
I don't think there is a definite answer to your question, it depends a lot on your situation, requirements, code base, deadlines, qualifications, etc.
It comes at the cost of more dependencies though (changing one thing may have impacts on many other things)
It also forces you to have a very modular design, which is usually a good thing if done right, but that's not easy.
C# provides a ton of things, which is a big benefit over C++. BTW, have you considered writing your engine and your tools using C#?
If you're considering C# for GUI in particular, then it's possible for you to make all your C++ tools command line driven, and create a GUI in C# to act just as a front end (if you know perforce, think of p4 vs. p4v, for example)
I don't think there is a definite answer to your question, it depends a lot on your situation, requirements, code base, deadlines, qualifications, etc.
I wrote a level editor in C++ with the Win32 API one time. Not doing that again. Next time I'm going to get the shared code into DLLs and call them from a C# GUI.
Author
Quote:Original post by janta
BTW, have you considered writing your engine and your tools using C#?
If you're considering C# for GUI in particular, then it's possible for you to make all your C++ tools command line driven, and create a GUI in C# to act just as a front end (if you know perforce, think of p4 vs. p4v, for example)
The engine must be C++ (school requirement), so the first isn't an option. As for the command line tools, I just started making GUI wrappers around my new command-line tools using C#, and absolutely loved how easy it was. That's one of the reasons I'd really like to use C# for tools development for my next project. My main concern is the rendering, since other things (like file formats) seem to work well as command-line applications.
Quote:Original post by Cantos
I wrote a level editor in C++ with the Win32 API one time. Not doing that again. Next time I'm going to get the shared code into DLLs and call them from a C# GUI.
A lot of people's problem with C++ is actually not the language itself, it's picking the wrong api/framework for the job. It turns out that microsoft doesn't provide any remotely decent api and framework for C++. The win32 api is awful, and so is MFC.
Using C++ along with a good framework like Qt however would probably be a much better solution overall than using windows forms in C#.
All our tools at work are written in C# and interact with our native engine via a managed C++ layer (except for the terrain editor, which was written years ago by an MFC fanatic and has grown too large to port). It's really not as hard to do as everyone thinks. For instance, a model viewer would need to know about models and scenes, among other things. So in the managed C++ layer you write a managed wrapper object for a model and for a scene, which contain pointers to native models and scenes. You expose functions in the wrappers that the model viewer needs like loading models and adding/removing them to/from the scene, and have them call out the the appropiate native code. All the model viewer needs is these wrapper objects, and it can interact with the engine to the extent that it needs.
MSDN has a few articles under C++ Interop that should get you started in the right direction.
MSDN has a few articles under C++ Interop that should get you started in the right direction.
Quote:Original post by Zlodo
A lot of people's problem with C++ is actually not the language itself, it's picking the wrong api/framework for the job. It turns out that microsoft doesn't provide any remotely decent api and framework for C++. The win32 api is awful, and so is MFC.
The WinForms framework is only part of it. Certain elements of C# (like Reflection, for instance) make it much more suited to an app like a map editor where you need to be able to enumerate and provide access to various properties of your objects and data structures. You also gain access to an incredibly robust standard library...if you've ever even poked around the PropertyGrid control then you know how useful it can be for tools development.
Quote:Original post by MJP
The WinForms framework is only part of it. Certain elements of C# (like Reflection, for instance) make it much more suited to an app like a map editor where you need to be able to enumerate and provide access to various properties of your objects and data structures.
True, but to achieve this reflection you first need to go through all the work of wrapping your native c++ classes into .net classes. I'd rather use Qt's property system directly in c++. Or ideally, have a common system to expose the c++ classes to a scripting language and to whatever script interpreter is used by the project.
Quote:You also gain access to an incredibly robust standard library...if you've ever even poked around the PropertyGrid control then you know how useful it can be for tools development.
For having used both, winforms pales in comparison with Qt. It's 2009 and it's long due for UI toolkits to fully embrace hierarchical layouts instead of making people specify control positions in pixels. Also Qt have tons of useful widgets, like MVC tree controls, lists and grids.
Quote:Original post by Zlodo
True, but to achieve this reflection you first need to go through all the work of wrapping your native c++ classes into .net classes. I'd rather use Qt's property system directly in c++.
How is making wrappers in C# any different from making a bunch of wrappers using QObject's? You're going to spend the same amount of time and end up with something that's, in the end, less robust.
Quote:
For having used both, winforms pales in comparison with Qt. It's 2009 and it's long due for UI toolkits to fully embrace hierarchical layouts instead of making people specify control positions in pixels. Also Qt have tons of useful widgets, like MVC tree controls, lists and grids.
I wasn't talking about just WinForms...the .NET Class Library is pretty much the best standard library you can get.
Quote:Original post by Zlodo
True, but to achieve this reflection you first need to go through all the work of wrapping your native c++ classes into .net classes. I'd rather use Qt's property system directly in c++. Or ideally, have a common system to expose the c++ classes to a scripting language and to whatever script interpreter is used by the project.
There are tools that you can run that will create simple managed wrappers for C++ classes. It is actually quite easy to get C++ libraries running in .NET.
Quote:
For having used both, winforms pales in comparison with Qt. It's 2009 and it's long due for UI toolkits to fully embrace hierarchical layouts instead of making people specify control positions in pixels. Also Qt have tons of useful widgets, like MVC tree controls, lists and grids.
This is what WPF is for and for an immature technology, it is quite useful and robust.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
