Jump to content

View more

Image of the Day

Working on an auto spawn system. #gamedev #indiedev #screenshotsaturday https://t.co/Mm2kfekz7b
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Choosing c# or c++ for game engine development

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 BlackBrain   Members   


Posted 24 May 2014 - 10:22 AM

Hi .


   I want to start developing a game engine . I have done it before using xna and c# . Now I want to have the power of cumpute shaders and all the nice DX11 features .

So do you think from c++ or c# which is the better choice for this purpose ?

I feel a lot more comfortable in c# . But as you know c++ is generally faster . I heard about .net native compile that is going t bring c++ performance for .net languages .


For saving objects in my last engine I used BinaryFormatter of .net that I didn't see any equivalent for that in c++ .

Since c# uses refrence concept does it mean that iterating through an array does not take any benefit from CPU's cache ?



#2 Bearhugger   Members   


Posted 24 May 2014 - 09:27 PM

Well if you're not comfortable with C++ then I doubt you will beat the .NET JIT-compiler at writing fast native code in C++, and with Microsoft brewing some native .NET compiler, the speed difference will probably become a lot smaller very soon. (Like compiled VB6 vs C back in the 90s.)


If you want to use C++ because it's your long-term goal to be proficient at it, this is a great opportunity. Using C++ to be able to eventually port to iOS and Android might also be a good idea. If you just want C++ to save a few CPU cycles then I wouldn't bother unless your project is such that it absolutely needs blazing-fast performance. Truth be told, C++ might be a good starting point, but it is not a panacea to slow code. For example, Ogre 3D, which is pure C++, is sluggish and slow, and Runic Games, who are not even making performance-hungry games, had to mod it to improve performance. I wouldn't be surprised if someone could out-perform Ogre3D using XNA.



Also, I'm not sure I'd recommend BinaryFormatter for saving objects during development. I use it in my game editor for saving stuff and I regret it. Whenever I want to refactor something in my code, it breaks binary serialization and I can't fix it by hand, instead I have to use a SerializationBinder, hack some translation code, then load and save ALL my assets, and finally recompile my app without the hack because SerializationBinder slows loading down to a crawl. (It was such a pain that I had to make a library for auto-generating a SerializationBinder.) If I had to code it from scratch again, I'd probably save my levels in XML or JSON and my data in a SQLite database, disk space be damned. I think that binary serialization in .NET is useful for in-process serialization like copy and paste, sending data between AppDomain, and over a network, but not for long-term storage, and especially not during development where stuff can be moved and renamed.

#3 frob   Moderators   


Posted 24 May 2014 - 10:44 PM


As far as languages go, both C++ and C# perform very well.

Most of the constructs used in everyday programming translate almost directly into common low-level instructions. Math operations, assignment, function calls, parameter passing, all of these boil down to virtually identical low-level code between the two. For this, there is practically no difference.

C++ tends to do a little better at systems-level code mostly because of a combination of the 1960's build mentality that it grew from and that the optimizers have been developed and focused on for so many years. The structure of the language requires a high interdependency, and tight coupling between modules, which was necessary 50 years ago when mass storage was measured in kilobytes rather than terabytes. C++ requirements of forward references (which C did not have) and the heavy use of templates (which are not classes, they require the compiler to generate code on the fly and test against an enormous number of potentially viable functions) means compile times get huge. Code must include headers for diverse systems and code gets heavily inlined and often elided. There are many C++ idioms that ONLY work well in the real world because of the compiler model where everything is incorporated, and then optimized away. For example, it is common for containers to follow a very long list of nested functions with ten or twenty or more nested function calls, only to end up with dead code that vanishes in release builds and a single array index. Or for another example, starting with accessors on a sub-object, nesting to more accessors on a sub-object, nesting to furhter accessors to sub-objects, and then reducing it into a single array index or reading at an offset into a structure. The cost is enormous compile times. A small module may require several minutes to build, an entire game engine may require several hours. But the optimizations are usually pretty good.

What C# is missing in heavy optimization, it generally makes up for in convenience and reduced development time. Programmers are constantly involved in the edit-build-run cycle. The language is well established at requiring less mental investment and is faster and easier to write good code, so the 'edit' part is faster. Dropping from minutes to seconds for compile time saves untold work-hours in the 'build' part of the cycle as well. Once you are in it, C# inherently includes a lot of functionality that is very useful to programming, such as reflection which gets used for automatic serialization and formatting as you mentioned above. If a feature is not available in managed code it is very easy to either wrap it up or invoke it directly. True the additional features and different build model have a bit of a runtime cost and storage cost, but I personally find that 15 minutes in C# is usually equivalent to an hour or two in C++.

For a large game engine there are portions you will probably want in C++ because of the heavy optimizations. But when it comes to raw productivity, C++ is not your friend.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

#4 kunos   Members   


Posted 25 May 2014 - 12:11 AM

To add to Frob's exceptional coverage of the situation, I would say that when it comes to build an Engine with integrated tools like editors a-la Unity, using C# is a huge avantage because of the very good GUI building support you get either via WinForms or WPF.

We've seen C# and .NET pushed down in the latest 2-3 years by MS itself..and C++ regaining a lot of ground in the gamedev arena.. but, as .Net Native and the news coming out of Redmond about a rebirth of .Net and future support on the XBone show that the jury is not out yet on this one.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.