We Keep Coding

C# or C++ for making a game engine (in depth) [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is best C# or C++ for making a game engine. I currently am a .NET C# developer and really want to use C#. Although I know C++ does support memory management and that is why a lot of big companies go for it. That being said C# is quicker in the development process and extremely familiar to me. Before anyone suggests it, yes I've used unity. I like it but want to go the long and hard extra stretch to own 100% of my own built game.
What do I lose by not going to C++? and what kind of libraries do I use, for graphics and stuff? Is that what DirectX is for? I'm trying to wrap my head around this and any help would be much appreciated.

I need some opinions
Perhaps I shouldn't presume to tell you what you need, but I think you'd be much better off receiving information you need to form your own opinion. Asking for opinionated answers (notice irony here) in my opinion isn't generally desirable here.
C# and C++ are both very powerful general purpose programming languages. Either language is 100% capable of creating full fledged high performing games. With that said, there are some (mostly) objective differences one can point out that may effect your decision.
Garbage Collection
Whether this is a pro or con for you is for you to decide. Some people want to save themselves work and have to spend little time taking care of memory. Obviously C# shines in this regard. C++ can have elegant and easy memory management if you know how to properly use smart pointers of course, but that's still more effort than garbage collection. If you're very concerned with having tight control over resources, then C++ might be more your thing.
Libraries
When you want to write software without reinventing wheels (and you should) a language's libraries can be just as important as the language itself. This isn't an obvious pro for either language, as both have lots of libraries supporting games. If you have to pick a winner though, I'd say it's probably C++. The language has essentially been the vernacular of game programmers for years now, and has a lot of maturity in this domain. C++ can directly leverage APIs as low level as OpenGL and as high as Ogre3D. There's no guarentee that your game will actually benefit from a C++ library over a C# library though. It depends on your use case.
Standard Libraries
Continuing on the theme of libraries, this could be a pro for C#. C and C++ are two languages that have an enormous amount of libraries available. If you only count their standard libs though, then things change. Some people don't mind, or even like this. One may also want a more expansive standard set of functionality however. C++ doesn't have a small or incapable standard lib by any means, but C#'s is definitely more feature rich.
Platform
Unless you're going to use Mono, C# is not portable. Mono is a great option, but it does have cons (that you'll have to research yourself). C++ can't tow a line like "Build once, run anywhere", but it does all the same offer damn good portability if that's what you're going for. With an OpenGL renderer (or some higher level wrapper API like SDL/SFML) you can build for pretty much any desktop environment. If you're only worried about making games for Microsoft platforms though, then this point is probably mute.
Virtual Machine or Native
This just like garbage collection is just a factor to consider. It'll be up to you to decide if it's right for your use or not. VM's sometimes have a stigma among game programmers it seems because of supposed performance issues. It's true, if C++ is used intelligently, it will probably be a better performing game. C#'s performance isn't anything to laugh at however. A lot of games that are written today can perform fine with a C# implementation. Is using C++ really an advantage if it means 450 FPS vs 400 FPS? Sure, there's a measurable difference, but it doesn't mean much to anyone playing your game, even if they have a 144hz monitor. Memory overhead is in a similar boat. Usually C++ isn't actually a necessity until you start getting into seriously heavyweight games.
Learning
Last but not least, consider the fact that you have tools you know, and tools you don't know. You already know C#, the time you have to invest learning is probably going to be much less if you choose to pass up on C++. C++ simply has additional concepts and responsibilities compared to languages like C# and Java. Some of these things you can choose to ignore. C++ won't hold you at gunpoint and force you to use multi-inheritance, and hey, that's probably easy to pass up on. Will you pass up on destructors though? Those are pretty important. What about the STL in general? Passing up on that is probably not a great idea, no best you learn STL if you're going to use C++. If you think this is worthwhile doing, then by all means go ahead. Again though, it's just something to weigh in.

Creating a game engine in C++ while learning C++ is a big challenge.
C# is more enjoyable than C++
Why?
In C++, pointers are powerful and you need to know how pointers work and how to use them
In C++, finding libraries is not as easy as pulling a nuget package
In C++, creating/refactoring header and source files is annoying
In C++, need to compile for every CPU architecture
In C++, syntax may be harder to grasp at the beginning
In C++, using the compiler and optimizing it is a topic on its own
But if you want your game/game engine to be fast then you should go for C++
When i see people coding for games in C++ they mainly use OpenGL but thats a common mistake since most of the non-console gamers are Windows users.
My advice is to first start creating a small game using DirectX, if you feel comfortable with it, then take the next step and create your own game engine

Unmanaged C# versus C++ [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am a wanna-be Games Developer and I prefer using C#. When I asked what the disadvantages of writing real-time applications in C# were I got 1 significant point back: Garbage Collection and the unpredictable impact it can have on performance.
My counter question is, what about Unmanaged C#? How does it compare (performance-wise) to C++? Is it a valid option for developing software?
I don't hear much about unmanaged c# and all the "unmanaged c# versus C++" questions I saw were unanswered or answered inaccurately. These questions were not on stack overflow.
EDIT:
I believe umanaged C# is "Unsafe Code".

Unsafe code in C# is not for developing separate applications. You can use unsafe code for some kind of time-critical operations, but generally it's not the most effective and the most convenient way of doing this. IMHO, it is primarily designed to give C# an opportunity to integrate with unmanaged dynamic link libraries and unmanaged code, so from my point of view the primary reason is INTEGRATION.
I can see 3 common ways of managed and unmanaged code integration:
Unsafe code in C# and P/Invoke. Build C# wrappers over compiled unmanaged DLLs.
Managed C++. Build managed assemblies over existing C/C++ code.
COM interoperation. Call Runtime Callable Wrapper from .NET client or call COM Callable Wrapper from COM client.
On the other hand, it's your architectural and conceptual decision: if you need a full memory and performance control, you develop in C++ or even pure C. If you need advantages and simplicity of modern language and modern technologies, you develop in .NET C#. Or you can use both, and how to integrate them is described above.

You can use C# to build games. The question is what exactly are you intending to do? What platforms do you intend to target, and how polished do you intend the finished product to be?
Others have mentioned Unity, which uses C# and provides a ready-made game engine and development suite. The only downside is that the free version has limitations.
If you want to build your own engine for the sake of understanding, look into XNA. Or you can use a wrapper around OpenGL like SharpGL. Or maybe you can find the long-dead Managed DirectX floating around somewhere. Or if you are really brave, you can use unsafe code and wrap GDI calls so that you don't have to deal with the horribly slow GDI+ implementation. The last two really aren't recommended, and only XNA is going to provide you more than a way to draw things on the screen. There are sure to be countless other possibilities, especially considering what becomes available to C# developers with Mono.
Whatever you decide, the garbage collector isn't going to get in your way, and unsafe code wouldn't be a solution if it did.
Edit:
As mentioned by cdoubleplusgood, XNA is no longer in active development. Look into Monogame and consider the wonders of cross-platform development a bonus.

For general purpose applications C# (managed) is a very suitable language with great performance. Unless you have extremely high demands you can certainly use it for games. Have a look at Unity:
Unity
Nevertheless, most AAA game studios use C++ as their main programming language. That being said, if you want a career in such studios you are better off investing some effort in C++.

How big of a jump will it be to go from C# to Objective C [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
How hard will it be to transfer from my existing expertise in C# to building apps for the iPad/iPhone in Objective C?

The language jump is OK. Once you get past the initial shock of [ and ]. However, the libraries and Framework shock will be substantial.
The Cocoa and Touch frameworks are significantly lighter when compared with .Net Framework, so at least you can look at the bright side, you have less to learn. But their underlying philosophy, layout and historic evolution path is very different from the C#/.Net framework. Whether this will be easy or hard, is difficult to appreciate. Some personal opinions:
The Cocoa way of building UI is light years ahead of anything .Net framework has today, Forms or WPF. It will be difficult to grasp at first, but if your grok it, it will make a LOT of sense. It is good ole' Model-View-Controller based on Smalltalk framework and will naturally guide you down a right path of designing UI.
Graphics, video, media are going to feel as from another planet when coming from .Net background. But despite their apparent arcane appearance, the Cocoa offerings are very powerful, although somehow low level.
Introduction to Cocoa Drawing Guide
Quartz 2D Overview
Introduction to Core Video Programming Guide
Core Audio Overview
Animation is going to be a huge sigh of relief. Cocoa animation is just plain easy to use, and there isn't anything equivalent in .Net
Introduction to Core Animation Programming Guide
If you do openGL instead of Cocoa native graphics, then is openGL and openGL is pretty much the same flavor on any platform.
Network programming is poorer on Cocoa side. You have some basic support and gotta admit that at least the API is designed that is really hard to do stupid stuff (it forces you to use async programming, so no more one-thread-per-client non-sense), but I'd bet you'll miss the .Net sugar utilities (WebRequest, WebClient etc)
NSConnection Class Reference
Introduction to Distributed Objects
XML parsing. Cocoa support is just plain primitive. At least, again, the XML parsing is event driven so is going to guide you toward better programs, but is complicated to put together.
Introduction to Event-Driven XML Programming Guide for Cocoa
Database. Is going to be a different world. You have the choice of going raw SQLite or Core Data. Core Data is better imho. Is a high level ORM and active record kind of stuff, with all the intricacies of the underlying storage abstracted away. Easy to use and powerful, as long as you ask it to do something it knows how to do. Unbelievably cumbersome to force it to do something it doesn't know how to do. True for any ORM, ultimately. You'll miss LINQ, and you'll have to forget SQL. The gist of it is that the DB programming experience from .Net just doesn't transfer to Core Data world. The alternative of raw SQLite will look more familiar, but is very low level, will feel more like programing 1990 ODBC than 2010 .Net.
Introduction to Core Data Programming Guide
Key-Value Coding Programming. This concept has no direct .Net equivalent. It may sound like some sort of simple dictionary, but in fact is way more powerful. It interweaves with the runtime engine of the Objective part of [Objective-C] and gives birth to some neat tricks. You'll need to understand Key-Value coding to make efficient use of Core Animation or Core Data. You can think at it as reflection on steroids. It can achieve some of the same tricks Linq-to-Objects can do, but is not going to be anywhere as elegant as Linq.
Is C++. Objective-C is a superset of C++ and is backed by recent drops of gcc, so you can fall back to C++ anytime. STL, functors, template metaprogramming, they all work. You can mix and match in the same application pure Cocoa and Core Objective-C with C++. You won't be able to do something like inherit an Objective-C class as a C++ class, but you will be able to communicate between a C++ class and an Objective-C object. Not sure what is the current status of boost or Loki support.
Many of the areas covered poorly in Cocoa have various 3rd party libraries, but I can't enter into comparison all Cocoa 3rd parties vs. .Net 3r parties, I have a life...
Overall, I would sum it up shortly as In Objective-C the entry bar is higher. Bring a brain.

In addition to Remus's terrific answer, you will also need to understand and be able to implement memory management. If you grew up on Java or .NET, this may be alien to you. Pay very close attention to this part of the tutorials, and practice this by intentionally screwing it up. You need to know what these errors look like and how they behave.
Good luck!

It's a decent sized jump, but you can learn enough to get up to speed in a few days.
Once you get the Objective C syntax and conventions down, you'll have to delve into the Cocoa libraries and frameworks, which are pretty substantial.
I would recommend getting a book on Objective C or iPhone development, or going through all the tutorials on the http://developer.apple.com site.
Once you get going, check out this site for good code examples for applications: http://appsamuck.com

I think if you know OOP you will be fine. The synthax is not usual as most programming languages though, e.g.
object.function(var arg1)
looks like
[object function[var:arg1]]
if I remember correctly.
If you have an Apple Dev ID and iTunes, you could go to http://developer.apple.com/iphone/index.action then go to the Getting Started videos (after which it should ask your Apple Dev ID at some point then launch iTunes). There you have a bunch of videos. The one called "Introduction to Objective-C and Cocoa Touch" can be a good start to look at.
Hope that helps.

The language isn't difficult but I found the development environment isn't quite as slick as VS in a few ways. For instance the interface builder is a distinct application to the coding environment leading to occasional synchronisation issues, and the compiler won't tell you if you typed an event name incorrectly.
Having said that the interface builder is gorgeous. You just need to remember to hit the save button before you flip back to the code.

C++ as first language for Windows game programming? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm a hobbyist programmer with a fair grasp of Python and I'm currently learning C. Recently I was talking to a colleague who also wants to learn to program. In his case, he wants to learn C++ as a path to Windows game programming using DirectX. Personally, I feel diving straight into C++ as your first language is a bit much - it's hard enough keeping motivated in an easier language, and I think it's better to learn another language to get your head round most of the basic concepts, then go into something like C++.
I found Python worked well as my first language as I'm more interested in network and web programming on Linux/Unix platforms, but for someone mainly interested in Windows game programming I was thinking C# might be a better choice as he could learn using Visual C# Express Edition and XNA, then switch over to Visual C++ when he's ready to start learning C++ and therefore already be in a familiar environment. I think memory management is a lot to take in, and C# at least handles that so he can put that off till he starts learning C++.
What do others think of C++ as a first programming language for this kind of application? Should I recommend he go for C# instead?

C++ should be fine. I think he is best off learning about memory management, pointers, etc. BEFORE jumping up to C# as he will understand how the program is working better. Otherwise, he will just see memory as being magic and the garbage collector will have no real meaning. It's always good to have a solid understanding of underlying languages (C, C++, Assembly, etc.) to produce the best code.

C++ is the main language used for most "serious" gaming titles. If programming for a major gaming studio then he needs to know the dirty little bits of C++.
Starting out with C++ might be a bit much for a complete novice. I would recommend C as a great starting point. You get familiar with the concepts of memory management and the other low level stuff before adding the complexity of C++.
Since C# is managed code, he would not be gaining the insights of the low level memory management. That will not serve him well when having to deal with C++. In this case, starting closer to the metal will help him in the long run.

C++ game programming is great. But unless you like total pain while you are learning to program, you might look at starting with XNA. This will allow you to work on the game content and logic instead of fighting with your engine code.
Now if you like pain go the DirectX and C++ route to start with.

I think it is better to thoroughly learn a language such as Java or C# before taking on C++. The reason I say this is because you can easily get bogged down in the details and intricacies of C++.
I struggled with C++ on and off (as a hobby) for a few years, then at Uni I was taught Java, stopped doing any C++, got a job doing Java for a couple of years, then moved into C++ dev. I picked everything up very quickly because I already knew what patterns and concepts I wanted to apply and it was just a matter of learning the syntax and weirdnesses and getting used to pointers again. I just had to learn HOW and not WHY. Taking on C++ as a first major language is learning HOW and WHY at the same time and it can be very confusing!
XNA is a good suggestion.

Python is good at game programming. See i-want-to-learn-game-development-which-language-should-i-use. Consider learning Pygame.
Pygame is a set of Python modules designed for writing games. Pygame adds functionality on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language. Pygame is highly portable and runs on nearly every platform and operating system. Pygame itself has been downloaded millions of times, and has had millions of visits to its website.

If he wants to get into the industry, then knowing C++ is vital, as the majority of game engines use C++. (I also developer should at some point lean C or C++)
However, if he wants to write games (as in, finish writing a game) then C++ may not be the way to go. It is very complex and has a lot of pitfalls that make it a slow language to develop in. It is not just the memory management, but things like the horrible stl related compile errors etc that make it very hard to get anything done when first trying to program.
Looking at something like C# or Python would be a better option, as they are far less complex languages and each have some good game library's.
If he decides that C++ is the right way to go, then I would recommend at least a rendering library. Something like Ogre3D at the very least. The reason for this is covered in this article Write games not engines. While writing (or trying to write) an engine from a base API is going to be a good experience, it is unlikely that the game will get finished.

Something you have to consider is existing SDK's, you probably don't want to program everything yourself. For example, there are pretty good 3D engines with different types of licencing that may suit you well.
So you should check outthe existing libraries and SDK's and the few languages you want to stick with together at the same time. Adapting to C++ or C# is not that difficult, the former is more strict and more demanding whereas it gives you more extensive control on memory, the latter allows you to focus on the main development area but takes the memory management in charge (mostly), which means you could have real-time issues.
At the end of the day, what help you can get to build your application will invariably outweight the small differences between those OO languages (to some extent).
There are lots of game engines, most are listed on this page. Of particular interest are, in the free world:
Panda3D (http://www.panda3d.org/), C++ and Python;
NeoAxis (http://www.neoaxisgroup.com/), essentially C# (.NET);
Ogre3D (http://www.ogre3d.org/), C++;
CrystalSpace (http://www.crystalspace3d.org/main/Main_Page), C++ and Python;
Esenthel (http://www.esenthel.com/), ...
Non-free packages include Unity, and others.
If you do not want any of those engines, there are still very good libraries like Qt for C++, that allows scripting - though not directly Python, you would have to embed it yourself - and others for C#, but the listing could get quite lengthy.

Typically, people run out of steam before completing their first game. Therefore, unless your friend has a track record of being doggedly determined, I'd recommend the most high-level option available. If you are choosing between C++ and C#, that'd be C#.

I would prefer XNA and C# for a quick and painless introduction.I would use C++, and a library like DirectX, for game programming after having some experience on the topic.Most of the most successful games have written in C++.

If your goal is to have fun, and actually finish games yourself (or in small teams) that are relatively small in scope, then I say C# and XNA.
If your goal is to work in the industry, on super big budget games with giant teams... Then C++...

CAD/CAM without C++ [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Is it possible to do CAD/CAM software without having to use C++? My company developed their software with c/C++ but that was more than 10 years ago. Today,there is a lot of legacy code that switching would force us to get rid of but i was wondering what the actual risks are. We have a lot of mathematical algorithms for toolpath calculations, feature recognition and simulation and 3D Rendering and i was wondering if C# can handles all of that without great performance loss.
Is it a utopia to rewrite such algorithms in c# or should that language only deal with UI.
We are not talking about game development here (Halo 3 or Call Of Duty) so how much processing does CAD/CAM really need?
Can anybody enlighten me on this matter? Most of my colleagues are hardcore C++ programmers and although i program in c++ i love .NET but i am having a hard time selling .NET to them other than basic UI. Does it make sense to consider switching to .NET in such a field, or is it just not a wise idea?
Thank you

If you have a lot of legacy code that would need to be rewritten, I don't see it making business sense to switch to a different language. Even if there were gains to be had from using a different language (which is questionable), the cost of testing and debugging the new code would more than overcome them. You also have a development team that are experts in C++. There would be a big productivity drop while they came up to speed on the new language.

C# Can interop with C++ code. You can start writing new code in C# and have it call existing c++ code when needed. It wouldn't have to be just for UI. Look into C++/CLI and the C# Interop methods for information on how to use existing c++ code with new C# code.
Also, I asked a similar question here:
C# Performance For Proxy Server (vs C++)

CAD/CAM applications are fairly calculation intensive, and speed will definitely be one of the criteria for selecting a package, so I would be wary of moving to a slower language.
You need to think very carefully about the reasons for switching language. Is it because you don't like C++, or because C# will bring real benefits. It is quite likely to slow your application down. Check out the C++ C# speed comparisons.
Computer Language Benchmarks Game C++ vs C#
In my humble opinion, you'd be better off keeping all of the toolpath calculations in C++, and if you really must move any code over to another language, move it over to a scripting language which the user can easily edit, without re-compiling.
I use CAD/CAM applications every day at work, and there are a number of things in the UI which get on my nerves. They would be simple fixes if only I could get at the source.
If your company makes a CAD/CAM application which has a UI written in a scripting language which I can tweak (Lua, Python etc), I'll buy a copy.
Hugo

Have a look at pythonocc. Its provides you with a python module that wraps the OpenCASCADE CAD kernel. OpenCASCADE is the sole industry strength open source kernel I'm aware of. Nice features are STEP and IGES support and the ability to generate FEM meshes from BRep data.

Another thing you need to consider is platform independence - if there is a possibility that you/you company need to migrate your CAD software to Linux/Unix (Of course, for bussiness decision), it will be quite painful. Currently, even C++ with MFC/Win32 calls gave us many headache...

The Open Design Alliance library is cross-platform. They have recently introduced a beta of the .NET version of their library. See my answer to Open source cad drawing (dwg) library in C# for more details.
Having said that I concur with the other answers here - if it ain't broken, don't fix it, both the code and the coders. MSFT still use C++, as does the ODA - their codebase originates in C++ & is wrapped for .NET.