Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
  1. Why most of the game engines use C++ to develop game?.
  2. Why not java or C#?.
share|improve this question
    
they do use C# and Java too. The main problem with those languages is gaming platform usually support C++ as their native development language. It's somehow community standard. –  Ali.S Jan 26 '13 at 18:28
add comment

closed as not constructive by Byte56, Ali.S, Maik Semder, Sean Middleditch, Sam Hocevar Jan 26 '13 at 21:01

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.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

I would say it's because C++ is, among major languages, the one that works at the highest level, without sacrificing access to low level control.

In C++ you have complete control of what is going on with your program, which may be desirable, especially for severely restricted platforms such as consoles.

For example: garbage collection as available in C# and Java is usually non-deterministic. Not only there is no accurate way for you to know exactly how much memory you're consuming at a given moment, but also you don't know when the garbage collector will run, probably slowing your main thread.

In consoles, even up to the Game Cube and dare I say the Wii, having extreme control of your program's timing is crucial to develop games that perform well. Many games time the game processing exactly while after a scanline has finished, and before the next one comes in. You only have a few microseconds to do work, which translates to a fixed amount of CPU ticks, so unless you know how exactly your code will be assembled, where your cache misses will be, and how long they will take, you won't be able to push the console to the limit. Doing this is impossible if a garbage collector is randomly popping in and messing with your timings.

This is of course historical. Modern consoles and PCs are more relaxed, and you can do a lot without really pushing the machine to the limit, so now you have XNA and PSM that let you program in C#, Android which lets you program in Java, and even Flash and HTML5 which let you program in variants of ECMAScript.

But even so, C++ will let you go to the edge when doing optimizations, as you can even eventually do inline assembly wherever you want. Java and C# simply don't let you do this.

share|improve this answer
    
Some counterpoints: Built in allocation functions such as malloc, new, etc. can have similarly horrific must-be-avoided-to-avoid-hitching runtime performance, and allocation is exactly when GC kicks in. The solution to both is to avoid allocation during gameplay. Similarly, inline assembly should be avoided: it's no longer even available in x64 on MSVC, and they can severely confound the optimizer. In contrast, intrinsics provide access to the same high-performance instructions while keeping the optimizer happier. Options like Mono.Simd do this for C#, although not as well yet. –  MaulingMonkey Jan 26 '13 at 20:50
    
@MaulingMonkey that's why especially in older consoles, you even have to roll out your own malloc and free if you want to push the hardware to the limit. All that is completely unnecessary with today's hardware (the 3DS is the only big exception), and today, readability and maintainability are much more important than taking the last millimeter in performance. I find that to be a good thing. –  Panda Pajama Jan 27 '13 at 5:28
    
Manually inlining assembly is the exact opposite to optimizing. –  Darkhogg Apr 2 at 21:22
    
@Darkhogg "exact opposite" is a very strong word. I suppose you're referring to the fact that optimizations by modern compilers are usually better than what you can do by hand, and inline assembly usually does more harm than good. That is true, but not in every case. As an easy example, when interfacing with hardware peripherals, you may have to work with volatile variables. Optimizers don't even touch them, and you can only optimize things with assembly in these cases. This stuff happens in games much more often that you would like, and are only doable when working in c/c++. –  Panda Pajama Apr 3 at 3:43
add comment

The generally used graphics libraries API, like DirectX and OpenGL are written in C, and provides you an C interface for usage. They have bindings to other languages, but most of these based on the C implementation, or tries to use the API procedures through his own native interface (eg. Java - JNDI) which is written mostly in C...

share|improve this answer
add comment

C++ is generally considered "better" than other languages, for several reasons. Mainly, almost all professional programmers know C++, but aren't as familiar with other languages. Therefore, there is a larger variety of third-party libraries and tools available for C++.

Also, Java and similar languages must run in a virtual machine, which is considered slower or less efficient than native code produced by C++.

However, in my experience, the speed and efficiency of these languages is not what makes the decision, it is only familiarity.

It should be noted that many games run on a C++ engine, but most (if not all) of the game's logic is implemented in a scripting language, such as Lua.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.