Sign in to follow this  
Ukrzuel

Managed C++ for game tools?

Recommended Posts

Hello everyone,

As most other C++ programmers who have been around for awhile, know that making tools with C++ with GUI from the ground up can be a big pain in the butt sometimes (unless you have a lot of reusable code from past projects), not to mention taking a huge amount of time. I'm not interested in using MFC for obvious reasons. I've gotten to the point where I really like C++ and could not see myself fully using C# for tool kits anymore. So my question is, will going into Managed C++ just for Level Editors and other tools be wise? How easy will it be to grasp the concepts to setup my tools? (I've never even looked at C++.net to be honest).

I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth. I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.

Do you recommend C++.net for tool sets? Or should I just stay with C#? I'm trying to end the habit of making tools using APIs like SDL to save time.

NOTE: This topic is not a (VS) topic for C++ vs C#. It's a topic to decide which will get results faster for building tool kits. I've invested enough time through the years in C++ to keep this as my language of choice.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305498992' post='4811244']
Hello everyone,

As most other C++ programmers who have been around for awhile, know that making tools with C++ with GUI from the ground up can be a big pain in the butt sometimes (unless you have a lot of reusable code from past projects), not to mention taking a huge amount of time. I'm not interested in using MFC for obvious reasons. I've gotten to the point where I really like C++ and could not see myself fully using C# for tool kits anymore. So my question is, will going into Managed C++ just for Level Editors and other tools be wise? How easy will it be to grasp the concepts to setup my tools? (I've never even looked at C++.net to be honest).

I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth. I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.

Do you recommend C++.net for tool sets? Or should I just stay with C#? I'm trying to end the habit of making tools using APIs like SDL to save time.

NOTE: This topic is not a (VS) topic for C++ vs C#. It's a topic to decide which will get results faster for building tool kits. I've invested enough time through the years in C++ to keep this as my language of choice.
[/quote]

Personally i'd recommend taking a look at QT , its quite easy to get started with, works on multiple platforms and with QTCreator you get a really nice UI design tool.

Share this post


Link to post
Share on other sites
Thanks, I'll look into QT. I've heard about QT countless times, even had the page bookmarked, never really went there though. I guess I really should be checking this out.

Thanks again.

Share this post


Link to post
Share on other sites
Managed C++ is the red headed stepchild of the .net world. If you don't want to use C# or Vb and are insistent on using C++ for GUI work the earlier Qt recommendation is as good as any.


For the record, I think using C++ for GUI work is a worse idea than using garden sheers to cut your toenails, but to each their own.

Share this post


Link to post
Share on other sites
I do agree that when I used C#, heck even in my BASIC days GUI applications were a lot less time consuming than C++. I looked at QT briefly, it does appear to do everything I need, heck I remember making an active toolkit with C# using XNA that had a real run time for maps. Was a lot of fun! :)

Was there a reason Managed C++ is a bad idea for toolkits? I wouldn't touch managed C++ with a flag poll for games though since I've never really jumped on board for .net games; however my tools are running on Windows 7. If I wasn't so keen on using just C++ and could break this bad habit, I would just use C# due to it's RAD Development. QT does appear interesting, that's for sure!

Share this post


Link to post
Share on other sites
To be honest, my experience with Managed C++ may be out dated, but they basically cludged a bunch of new operators and keywords on top of C++ to sorta support .net, then in the following release basically deprecated them all and used a different set of cludges. Managed C++ was as close to C++ as C# was, without some extraordinaryly arbitrary memory access rules.

It may have gotten better since, but the first two iterations of Managed C++ were pretty awful.

Share this post


Link to post
Share on other sites
For the record:
"Managed C++" was the first attempt at gluing C++ into the dotNet framework. It is now deprecated and shouldn't be used by anyone.
What you're talking about is called "C++/CLI".

IMO:
C# is great for tools dev. C++ is great for engine dev.
C++/CLI is really ugly ([i]it's basically C#, but with really cumbersome syntax[/i]), and should only be used in the rare cases where you want to plug some engine code into your tools ([i]i.e. just use it when you're gluing C++ and C# code together[/i]).

Share this post


Link to post
Share on other sites
Thanks for all the advice. I know when I did C# before with my Editors, I would embed XNA into my form so I could tile, drag and drop, plus add collision areas, ect... If I end up using C#, will I be stuck with XNA? I could use slimDX, however I've never used Slim before. I still think GDI+ would be too slow, not to mention dragging and dropping enemies on the screen would be a nightmare.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305534629' post='4811346']
Thanks for all the advice. I know when I did C# before with my Editors, I would embed XNA into my form so I could tile, drag and drop, plus add collision areas, ect... If I end up using C#, will I be stuck with XNA? I could use slimDX, however I've never used Slim before. I still think GDI+ would be too slow, not to mention dragging and dropping enemies on the screen would be a nightmare.
[/quote]

C++/CLI isn't bad to use but as Hodgeman says you should stay away from it unless you need to embedd a third party tool lib or some of the engine code into your tools pipeline. The syntax of it is close enough to C++ there are some new keywords and when a class needs to be visible by C# it needs to be a ref class and every "gcnew" has "^" as its pointer syntax.

When doing your tools in C# however your productivity is for bigger then writing pure C++ tools.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305498992' post='4811244']
I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth.
[/quote]

By "swapping back and forth" do you mean swapping code files back and forth or do you mean the language change?

If by that you mean swapping code files, I would recommend putting them into a .lib or .dll file.

If by that you mean swapping languages, I would recommend using wxWidgets. It is great for making tools and several game companies use it for their internal tools (when using C++).

However, it might be worth learning C#/WPF for building your tools. Some may consider it fast for prototyping and if you are looking to create tools professionally, a lot of studios use C#/WPF for their tools.

Share this post


Link to post
Share on other sites
Thanks Exoity, what I some what dislike is, spending hours absorbed in c++ where I'm in a very protective mind set for how I code, then going into C# where I'm not required to be as watchful, sometimes causes me to loose that focus when I go back into c++. I'm not sure if this makes any sense or not? I can tend to get a bit lazy when working in c# because I know I can get away with it, but when I go back to c++ I don't want to be in that same mind set. Considering I will be spending a good chunk of time with tools and my engine, I was trying to stay with just c++ if I could, taking advantage of .net forms.

Share this post


Link to post
Share on other sites
Umm sorry for my constant questions. I know I can get XNA in a Form window in less than 10 minutes and have a map able editor in about 30 minutes with just tiling to a grid (Mid you the code would be messy). I'm finding maybe using C++ will just cause more of a headache than needed for tools development. I have no problem using C++ for the engine side of things, maybe I should just stop being so one sided to just C++ and jump on board to a RAD language for my tools.

I don't really need to use C++ for the tools because I'm outputting all of the data in files which will be loaded into the engine and put to work. Heck, I could use BASIC and still accomplish the same task. My main issue is that GDI+ is usually too slow. I require some heavy graphic drawing in my editor, this is why I was thinking of XNA.

The one thing I hated about programming was the endless options, it's not like breathing.

If I find myself unable to leave c++, I guess wxWidgets with OpenGL would be an option.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305610172' post='4811788']
Umm sorry for my constant questions. I know I can get XNA in a Form window in less than 10 minutes and have a map able editor in about 30 minutes with just tiling to a grid (Mid you the code would be messy). I'm finding maybe using C++ will just cause more of a headache than needed for tools development. I have no problem using C++ for the engine side of things, maybe I should just stop being so one sided to just C++ and jump on board to a RAD language for my tools.

I don't really need to use C++ for the tools because I'm outputting all of the data in files which will be loaded into the engine and put to work. Heck, I could use BASIC and still accomplish the same task. My main issue is that GDI+ is usually too slow. I require some heavy graphic drawing in my editor, this is why I was thinking of XNA.

The one thing I hated about programming was the endless options, it's not like breathing.

If I find myself unable to leave c++, I guess wxWidgets with OpenGL would be an option.
[/quote]

You do realize that absolutely none of those technologies are exclusively tied to C++, right? OpenGL, DirectX, wxWidgets, all of the have C# bindings available.

I will agree with the decision you are coming to 100% though, using C++ for tools is mostly a dumb thing to do, especially if your end result is a language independent file.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305498992' post='4811244']
I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.
[/quote]
It's good to be a polyglot. You learn a lot about your primary language, if you also know well other languages. Mastering C# will help you with using OO features in C++, as well as with new C++ 2011 features. C++ is really not object "oriented", it just allows you to use objects. Also, if you want to write fast C, it's good to know assembly ;)
OK, if you have to work with 5+ languages, then you are spread thin. If it's below that number, you'll be fine.

[quote name='Hodgman' timestamp='1305507188' post='4811276']IMO:
C++/CLI is really ugly ([i]it's basically C#, but with really cumbersome syntax[/i]), and should only be used in the rare cases where you want to plug some engine code into your tools ([i]i.e. just use it when you're gluing C++ and C# code together[/i]).
[/quote]
Huh. C++/CLI looks like C# to you? C++/CLI is not a language of itself, it is C++ with support for CLR objects. If you want to consume or create CLR objects, you have to use CLR data types in System:: namespace. Within methods you are free to use std:: or boost::. The C++/CLI syntax for .NET types is quite similar to std vectors. To remind you of the type of variable you use, CLR objects use ^% operators instead of *&.

You can also define which files within your VC++ project have CLR support (/clr switch). I usually create ManagedClass.cpp and NativeClass.cpp. For NativeClass.cpp I remove CLR support in Release build and add SSE2 optimizations.

With Reflector you can also see your compiled .NET code as Managed C++ (old syntax). It speeds up the translating from C# to C++.

[b]As to the main question: should you use C++/CLI as a major development language. My answer is NO.[/b]
C++/CLI doesn't even have IntelliSense in VS 2010. Visual Assist X gives you that support though. C# is the language of choice for .NET development, C++ for native. C++/CLI gives you much faster interop than P/Invoke, as C++/CLI knows how to work with both CLR and C++ data types. But mind you, tight loops should be either in CLR or in native, the context switch isn't free (although it is faster than using P/Invoke).

Share this post


Link to post
Share on other sites
[quote name='0x00' timestamp='1305626880' post='4811859']
Huh. C++/CLI looks like C# to you? C++/CLI is not a language of itself, it is C++ with support for CLR objects. If you want to consume or create CLR objects, you have to use CLR data types in System:: namespace. Within methods you are free to use std:: or boost::. The C++/CLI syntax for .NET types is quite similar to std vectors. To remind you of the type of variable you use, CLR objects use ^% operators instead of *&.[/quote]I didn't say it looks like C# - I said it's got a very cumbersome syntax compared to C#.

e.g. in C++/CLI you've got [font="Courier New"]ref class[/font]/[font="Courier New"]value struct[/font] instead of [font="Courier New"]class[/font]/[font="Courier New"]struct[/font], and you've got [font="Courier New"]^[/font]/[font="Courier New"]%[/font] instead of C#'s automatic reference handling.
i.e. it can do everything that C# can (which is why I said it's [i]like[/i] C#), but the syntax for doing so is a lot more verbose than C#'s.
Also, it is indeed a language of itself ([url="http://www.ecma-international.org/publications/standards/Ecma-372.htm"]ECMA-372[/url]). There's certain programs which are valid under ISO C++ but are not valid when compiled under C++/CLI (mostly due to the new keywords).

[Edit]Your new word of the day: [url="http://en.wikipedia.org/wiki/Hyperbole"]http://en.wikipedia.org/wiki/Hyperbole[/url]

Share this post


Link to post
Share on other sites
If you love C++ you should definitely stick with Qt.
I made a leveleditor myself with Qt and I have to say that it worked pretty good.

What you also should not overlook is that Qt has one of the best documentations I've ever seen.

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1305627786' post='4811864']
I didn't say it looks like C# - I said it's got a very cumbersome syntax compared to C#.

e.g. in C++/CLI you've got [font="Courier New"]ref class[/font]/[font="Courier New"]value struct[/font] instead of [font="Courier New"]class[/font]/[font="Courier New"]struct[/font], and you've got [font="Courier New"]^[/font]/[font="Courier New"]%[/font] instead of C#'s automatic reference handling.
i.e. it can do everything that C# can (which is why I said it's [i]like[/i] C#), but the syntax for doing so is a lot more verbose than C#'s.
Also, it is indeed a language of itself ([url="http://www.ecma-international.org/publications/standards/Ecma-372.htm"]ECMA-372[/url]). There's certain programs which are valid under ISO C++ but are not valid when compiled under C++/CLI (mostly due to the new keywords).
[/quote]
You said: [i]it's basically C#, but with really cumbersome syntax[/i]
It is CLR, but the syntax is different. Otherwise you could also say that it's basically VB.NET.

C++/CLI might be formally a separate language, but in VS 2010, you only have C++ listed as a language. Then you can select ATL, CLR or MFC C++ projects. As for certain programs not compiling under CLR: you can specify CLR support on file level, or even only on a code block using [i]#pragma managed[/i],[i] #pragma unmanaged[/i]. You can't switch this way between C# and VB.NET :D

Share this post


Link to post
Share on other sites
[quote name='FelixK15' timestamp='1305627814' post='4811866']
If you love C++ you should definitely stick with Qt.
I made a leveleditor myself with Qt and I have to say that it worked pretty good.

What you also should not overlook is that Qt has one of the best documentations I've ever seen.
[/quote]

What does QT use for rendering graphics to the screen?

For example, if I clicked at (16, 32) on a bitmap, could I have a graphic drawn at that location. This is pretty much all I need, which is easy to do in GDI+ but very slow at the moment. I just need a buffer pretty much and I'll use my normal way of exporting locations for objects, ect... plus an array for the tile locations.

I'll check out the QT website some more, I did watch some youtube videos and must same I'm impressed with how fast I had seen a window with buttons and text boxes up and running.

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1305610810' post='4811792']
You do realize that absolutely none of those technologies are exclusively tied to C++, right? OpenGL, DirectX, wxWidgets, all of the have C# bindings available.

I will agree with the decision you are coming to 100% though, using C++ for tools is mostly a dumb thing to do, especially if your end result is a language independent file.
[/quote]

You bet, they're just APIs. I mean I could honestly make a level editor with C++ and say SDL or SFML, using a custom gui I'll create like I've done in the past. However, it takes a long time to get this done, but once complete it's working and good to go, and not too hard to make improvements. What I'm attempting at doing here is moving with the times. C++ has been my language of choice for a long time, however RAD will save me a ton of time in the future. I'm planning a lot of new projects in the coming years, and will be offering some services for others, therefore I'm trying to pick the right route for tools development now.

I don't believe I will ever sway away from c++ for many more decades to come, unless it becomes obsolete with some crazy new technolgoy and is unusable (which I doubt will happen in half my life time).

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305630123' post='4811880']
What does QT use for rendering graphics to the screen?
[/quote]
It depends on the platform. But for speed, you'd have to go outside of QT wrappers.

Mind you, cutie isn't that cute, since you immediately know if a GUI has been made using QT or not.

Share this post


Link to post
Share on other sites
[quote name='Ukrzuel' timestamp='1305630123' post='4811880']
What does QT use for rendering graphics to the screen?

For example, if I clicked at (16, 32) on a bitmap, could I have a graphic drawn at that location. This is pretty much all I need, which is easy to do in GDI+ but very slow at the moment. I just need a buffer pretty much and I'll use my normal way of exporting locations for objects, ect... plus an array for the tile locations.

I'll check out the QT website some more, I did watch some youtube videos and must same I'm impressed with how fast I had seen a window with buttons and text boxes up and running.
[/quote]

There are several classes you can use for rendering.
[list][*]QImage[*]QPixmap (which I use for rendering)[*]QBitmap[*]etc.[/list]To draw the content of these classes you need to inherit from the class QWidget and overload the function repaint() which gets called everytime your widget needs to get repainted. In this function you need to use the class QPainter to finally draw something on the screen.

Share this post


Link to post
Share on other sites
[quote name='0x00' timestamp='1305633460' post='4811895']
It depends on the platform. But for speed, you'd have to go outside of QT wrappers.

Mind you, cutie isn't that cute, since you immediately know if a GUI has been made using QT or not.
[/quote]

I guess for a tool like a 2D leveleditor the rendering speed of Qt should be more than enough.

Share this post


Link to post
Share on other sites
Alrighty, so my options look like:

1. C# Forms with embed XNA (Which I've done before)

2. QT using OpenGL/Direct X for displaying graphics

3. C++ Using SDL, ect... To make the editor from scratch. (I've done this a few times, mind you making the GUI was a pain in the butt)

After my day at the office I will research more into QT and see if this will be practical.

Thanks again.

Share this post


Link to post
Share on other sites
Thanks Felix, I was reading a bit on QPainter, wasn't sure how powerful it was going to be. Mind you when I program anything from a game to an editor, I make sure it only draws what you can see. However having a 2000x500 buffer to draw on might be too big for some software rendering. I could just make different buffers for every few screen width/height if I had to.

Edit: I was just looking on the SFML website:

http://www.sfml-dev.org/tutorials/1.6/graphics-qt.php

Pretty easy setup with QT!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this