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

What to use? Tao, SharpGL, OpenTK, DirectX P/Invoke, XNA, MDX, SlimDX, Windows API Codec Pack [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 7 years ago.
Improve this question
Back in the day it was easy; You made your own 3D stuff, then came DirectX, then came OpenGL. For .Net developers MDX was nice. Then XNA took over for MDX, but it its not the same. XNA seems to be very game-centric with all the content pipelining and preloading of fixed models and stuff.
So where do we stand now? After a couple of days of reasearch/trial&error I feel everywhere I look I find half developed libraries, libraries with overhead, severe limitations or libraries that are overly complex.
I want to do "free-hand" 3D stuff. For instance displaying 200k dots on a screen in 3D and move them around at 30fps (Kinect depth image). I want to make 3D screensavers, audio analysis plugins, etc. All of which is not prefabs for a content pipeline, and which require high performance. And (ehm) I want to do it from .Net.
Anyone have experience with libraries that are easy/understandable and still gives some fair amount of freedom and speed?

I seem to have landed on OpenTK. I think it gives more or less direct access to the OpenGL API and doesn't require loads of dependencies.
It is comparatively easy to understand. It requires few (and understandable) lines of code to get started. It doesn't hold the objects for me so I'm free to change anything for each pass, which is great because I'm mainly working with unsafe pointers to memory.
It is of course difficult to combine speed with ease of use. Speed requires talking directly to the 3D API while ease of use requres abstraction. Therefore this must be considered a lower level API than some of the others I've tried. If I wanted to do some prefab character animation then XNA would probably be a better choice, but for my use (described above) this seems very promising so far (4-5 hours of hacking).
Some sample code:
private void Render()
{
// Every frame
GL.MatrixMode(MatrixMode.Modelview);
GL.Clear(ClearBufferMask.ColorBufferBit | ClearBufferMask.DepthBufferBit);
GL.LoadMatrix(ref cameraMatrix);
GL.Begin(BeginMode.Points);
// Here I can add lots of points. I add 200k without any big problem.
// It seems these points could have been passed in as an array pointer too,
// but I'll look at that later.
GL.Vertex3(x2, y2, z2);
GL.End();
glControl.SwapBuffers();
}

If you liked MDX, SlimDX should be right up your alley. It's basically a replacement for MDX, but with a lot of the questionable design decisions fixed up, and a lot more functionality included. Anything you had with MDX, you will find present in SlimDX in one form or another.

Alternatively there is another C# wrapper package for OpenGL: OpenGL DotNet. Works great for me! Check it out at http://www.taylaninan.com/opengl-dotnet.php .
It wraps OpenGL up to version 4.4 and supports over 550+ OpenGL Extensions. It also supports GLU, GLUT, FreeGLUT, DevIL (Developer's Image Library), ILU and ILUT for DevIL.
It a low level API for the above libraries.

We faced a similar issue some time ago and the following represents our opinion only of course. One of our main concerns was that the library should be versatile, produce 3D images of very good quality, free, and not put loads of extra constraints on the installer, i.e. like with XNA where you have to have the correct files installed. This seemed like a possible source of headache. In the end we settled for DirectX and wrote the GUI in C#. All needed interaction with the 3D was done with wndproc. This provided us with both the power of DirectX and the ease of GUI development with C#. We haven't regretted this at all.

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++...

gaming with c++ or c#? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best language for programming a game project and why?
Why is the game programing world dominated by c++?

This is kind of a difficult question to answer. For the most part, C++ is a "better" language for programming games in that it gives you so much direct control over memory management that you have more options to fine tune your performance. That, along with the fact that C++ has been around ages longer than C#, have lead to its current dominance in the game industry.
However, these days, with the .NET platform and C# becoming so much more mature, its not easy to rule it out as a very strong contender in the game programming arena. I think this is especially true for the near future, as .NET 4.0 and C# 4.0 will bring in a whole new era of multi-threaded and concurrent programming that could bring some massive performance gains to their platform. With multicore CPU's taking the desktop computing world by storm, and massively-cored CPU's only a short step behind .NET/C# 4.0, I think the ease of developing multi-threaded applications with .NET and C# 4.0 will give C++ a run for its money.
In the end, it will entirely depend upon how much control you think you need over memory management, and whether that control is worth the effort in the arena of massively parallel games. If you need that control, and think you can deal with the effort of writing a highly parallel game in C++, then you'll probably gain something from it. Otherwise, I would say C# 4.0 would be the better option.
2011 Update:
It should probably be noted that, now two years on from when I originally wrote this, Silverlight games, particularly Silverlight on Windows Phone 7, have become a large and rapidly growing platform upon which games, often quite advanced games, are being developed. Gaming on WP7 has exploded since the platform first launched in Nov. 2010, and already WP7 has more games developed for it than competing platforms. Given the ubiquity of mobile devices and the popularity of playing games on them, I think that is a strong indication of C#'s power and capability as a game development language. Quite a few WP7 games are fully 3D, graphics intensive games.

For commercial / bigger game projects, C++ is probably the best option. However, if you're thinking of doing smaller, indie type games, there's nothing stopping you going with C# or even Java.
I've done several small games with C++, and one with C# using the XNA Framework, mostly for curiosity. Currently I'm working on a platformer game using Java and LWJGL (Lightweight Java Game Library). And guess what? It's working absolutely fine, plus I get cross-platform compatibility practically for free! The reason I started this project with Java was to see if I could create a nice OpenGL-accelerated game using Java instead of C++ I've normally used. So far it's working very nicely for me, I was really suprised actually. =) To be honest I've become a bit tired with C++, coding in Java feels much more productive for me currently (big thanks goes to Eclipse IDE!).
So, for smaller games you can definitely have success with Java or C#, no need to bother with C++, unless you're doing something that needs 100% of the possible performance. XNA might be the easiest option to get started with, although as for myself I most probably won't be using it again since it's basically Windows only (plus Xbox 360)..

Games are some of the most hardware intensive applications you can run. People program games in C++ for the performance, although there are a few games coming out nowadays written in C#.
This question has been asked before, check the following posts for more details:
Viability of C#/.NET as the new standard game dev platform?
https://stackoverflow.com/questions/19642/suggested-gaming-platform-to-learn-direct-x-c-open-gl-or-xna

It took years to get game developers off assembly onto C, then it took more years to get the industry onto C++. The reason is always the same ... "C will be too slow", "Objects will be to slow". There is enormous investment in code (engines, previous games, etc.) and talent in the industry in C++. It will take a long time for that to shift -- just as it has in the past. Someday, games will be developed in managed code, but it will take some time.
Meanwhile there are engines written for .NET in C#.

I think you'll find that, when you create your own game, that being CPU bottlenecked (the only aspect on which language choice has any effect) is the last thing you need to be worried about. It's much, much easier to be bottlenecked by the GPU. Hell, with today's minimum of 2 cores, I would find it impressive if you even managed to ever reach 100% CPU usage because that would require a perfect workload division to utilize the 2 or 4 cores of the CPU.
Generally, it's much too common for me to run a game (presumably written in C++) to see it use at most 50%-60% of my CPU. And can you then really speak of a bottleneck with the language that you use, or a bottleneck of the algorithms used that don't allow you to scale across more than 1 CPU core? So even in a situation where you run into the limits of a single core, it's still possible to (theoretically) double your performance by optimizing your algorithms before you can truly say you're being limited by the language.
And this is only going to increase in the future with the advent of 8, 16 and 32 cores. You really don't want to have a game that's only capable of using only 1 core out of 32.
The real reason why C# isn't being used in the industry: there's no reason compelling enough for game studios that have invested a lot of money into their C++ code to switch to C#. Not just their code, but their developers are already very good in C++ so it would be odd to switch to C# for "ease of use" when that actually means a lot of new challenges to overcome and a lot of money to rewrite existing code. And after all that, you've got new code that's only supported on the PC (with Mono for Linux support) and Xbox 360. No PS3, no Wii. So you've just limited yourself for little gain.

If you use C++, you have a much larger codebase, although this shouldn't matter for most games (except 3D games or games that'll need libraries like physics engines). C# could be easier to write, depending on how much experience you have with it (or how much less/more experience you have with C++).
Also consider using some sort of game creation tool like XNA Game Studio or similar, they often can give you all sort of help with usual stuff.

'Performance' is a red herring. Yes, games are just about the most demanding application that most consumers will run. However, most of the heavy lifting can be done with dedicated hardware, which will beat a software solution in any language any day of the week. The proliferation of Flash games should be proof enough that in most cases we have performance to burn (and now that we have some decent implementations I think we'll soon see games apearing in Javascript too).
I think it's just that many other languages are billed as business focused, or academic, or statistical, and developers on the whole haven't really felt the need to challenge those assumptions.