• Advertisement
Sign in to follow this  

Is it such possible to create fast games without using C/C++ ?

This topic is 1831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

 

Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Huge games like EVE are written in Python. Many others are written in C# or Java (say, Minecraft, Runescape). Insofar, it is very possible not only to successfully write a game in "not C/C++" and to find a job in the industry.

However, I find the "I'm starting to think that I never will be" bit somewhat of a show-stopping attitude. It is most definitively not something you want to say in an interview. Edited by samoth

Share this post


Link to post
Share on other sites

But on the flip-side, huge games like EVE have their core written in C++ (for speed), with Python layered over it (for ease of coding and convenience).

Many games are actually written in two languages: C++ and a scripting language (often Lua or Javascript).

Share this post


Link to post
Share on other sites
Hi,

 

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

 

Thanks.


From the point of view of working in the industry: You'll probably need some C/C++ knowledge.

From the point of view of just making a game: Things such as GLSL/HLSL shaders can make a huge difference to the performance of your game, and there's no reason why a shader uploaded to the GPU from C++ will be any faster than one uploaded from javascript / C# / python. For any core language you are using, algorithmic optimisations have the largest effect on a games performance, followed closely by memory optimisations (e.g. compression etc). A game written is something like python which uses the right data structures and algorithms, should be able to perform closely to an equivalent game written in 'vanilla' C++. You may find that computation heavy code will run slower than the equivalent C++ code, although you may be able to make use of middleware to claw back that difference (e.g. using a good physics engine). The biggest win from C++ is still the ability to use SIMD optimisations. Mono.SIMD goes someway to providing an alternative (although not sure if it's really worth the effort). The only other common optimisation is to make use of multiple threads, which you should be able to use on most decent languages these days without a problem. In a nutshell, your computer has a lot of horsepower available, and so the language choice shouldn't pose a barrier to accessing that.

Share this post


Link to post
Share on other sites

There are two separate questions here:

* does C/C++ perform better than X/Y/Z?
* is it important to learn C/C++ to get a job in the industry?

Anything that compiles to native code is going to run faster than something that doesn't. This is the reason engines are built in C++. But, as Servant of the Lord points out, most larger games use a high-level scripting language for actual game logic. There are many reasons for this: separation from engine/low-level code, reducing the amount of compiling that's required, allowing less technical users to script game logic, etc.

I think it's important to learn a C-like language, as it's the basis of many low AND high-level languages, but I would argue that knowing C/C++ inside and out is not a necessity unless you're working on console games, or working on game engines directly (building them, or extending them beyond their original design).

Edited by snugsound

Share this post


Link to post
Share on other sites

All that can be said is you can write an equivalant game in a different language, with the same speed.

That being said, it all comes down to how it was coded. You can write a fast game in C# or Java if coded correctly, and a bloated slow game in C++.

 

There are reasons why others like the language they chose. So in the end, it's what you're most comfortable with. Unless you are going for industry, learn what you can on everything!

Share this post


Link to post
Share on other sites

I don't follow. Shaders are shaders. They're not touched by whatever VM you're using. They get passed from the API (DirectX/OpenGL) to the driver and from there to the GPU. The only difference is that if you use C++, chances are that the API functions jump through less hoops to get to the driver whereas in Java for example, you must use a wrapper and the VM's native interface. VMs don't optimize for video cards, drivers do.

Take shaders for example, one of the most important visual pieces of a game.  Shaders are hardware scripts of sorts, it's a where you script an action for the video cards shader model to perform on your graphics.  This is an area where .NET, XNA and C# are actually starting to prove themselves faster than C++ and Direct X.  The C# builds are optimizing to the exact video card on the players machine giving them access to some higher level shader API's that would not be available on a common portable build that C++ would make.

Share this post


Link to post
Share on other sites
There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

On a more useful note...

@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

If you use something like Irrlicht (with C++) or Irrlicht.NET (with C#), they should both be very similar in difficulty.

(Though unfortunately like most .NET bindings (XNA included) the Irrlicht.NET is quite unmaintained.) Edited by Karsten_

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357753246' post='5019541']
@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

[/quote]

 

I just was wondering if there are another options to design powerful games without falling in C++. I don't want to be misunderstood: I like C++ (I'm still learning it), but it seems that programming on it is the only way to get fastest games. It's a question, not an affirmation.

 

By the way, I thank all the past and future feedback.

Share this post


Link to post
Share on other sites

As mentioned by others, any language that compiles down to assembly and isn't running in a virtual machine would do decently. C++ (and plain C) have been the industry standard for awhile because they are very cross-platform and have a few features and benefits that let you eek even more speed out of computers with minimal effort (but at the cost of making the language more complex and easier to make mistakes with).

 

The two things that make C++ in general slightly faster than other languages is (A) C++'s ideology of "Don't pay for what you don't use" (empowering developers) and (B) C++'s language specification letting compilers implement the language however they choose (letting them taking interesting shortcuts and optimizations) as long as the result comes out the same (empowering compilers).

 

If you're learning C++, I strongly suggest you research the new features offered by the newest standard of the language: C++11

C++11 makes C++ safer and easier to learn, while actually improving speed in some common situations.

Share this post


Link to post
Share on other sites

Personally I think C/C++ is beautiful. You haven't learned programming until you are at the hardware level C/C++ allows you to be at. Still, for a newcomer - learning C++ (or even just C) is a bit overkill. As all the others, I do suggest starting with something more abstracted (Java/Python/C#/you name it).

Share this post


Link to post
Share on other sites

You should use whatever you like, however it will also change what kind of jobs you can do or you can't.

 

For example you can always go down the web development road (browser, flash, html5, webgl games) and nobody will care if you can use C/C++.

For mobile games C/C++ might be important or not, it depends. If you develop for android I believe C/C++ is not really important most of the time. I don't know how other mobile OS's work with C/C++.

 

Anything desktop related, C/C++ might be a requirement.

For big studios, probably, maybe they have game play programmer positions that only require some scripting language. Tools and pipeline development will probably also possible without C/C++. If you want to go down the engine development road, chances are getting smaller.

Smaller studios might not rely on C/C++ at all, maybe you have more luck there.

 

Anyhow, it's possible to work in gamedev without C/C++.

 

Besides if you want to write a really fast game and don't want to use C/C++, you can always use Assembly. biggrin.png

Share this post


Link to post
Share on other sites

When I was asking this question I decided to email and 'industry veteran'. He said that when he employs people he is looking for C++ developers. As a Java coder wanting to be a game developer, this kind of gave me the urge to learn C++. In my opinion, I think C++ gives you a lot more access to your machine and code (if that makes sense) whilst Java is a lot easier to code. But, this could just be because I've been coding in Java for two or so years.

 

The only problem I ever have with C++ is trying to use external libraries. The Windows SDK sucks ass and requires a lot more code than writing windows apps in Java. I always get compiler errors from Visual C++ and it usually takes me an hour or two (3 days in the case of CUDA) to get the IDE to stop being a pain in the ass. In the case of Java, it's just referencing a single file then writing your code. In the case of C++, add a bunch of DLLs to here and here then add these include files to your compiler's include folder.... It's just a pain in the ass. I wonder if there's a way to write straight to the graphics card in C++ so I don't have to bother with any external libraries.

 

My advice would be that C++ is a good choice but if it's too hard at the start you should try an easier language and move onto C++ later.

Share this post


Link to post
Share on other sites
There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

 

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.

 

IL gives you portability, and sometimes that's exactly what you need. The Just-In-Time compilation technology is getting better all the time, and it can do run-time optimizations that static compilers just can't. Likewise, static compilers can do other optimizations that JIT compilers just don't have the luxury of time to afford.

 

I actually prefer C++ for most things myself, because its what I know and am used to, but its not the case today that JIT-compiled languages are so much slower than native languages that the conclusion is foregone. Native languages mostly shine brightest when you have to get down really low and control/influence exactly how memory is organized and accessed, or to employ hardware features that a language like C# just doesn't expose at a low level (say, SIMD or intrinsic instructions). In other words, the really processing-intensive, big-data kind of things. For the 90% of your game code that just deals with mundane game logic, flow control, messaging queues, etc, native code doesn't offer any clear speed advantage, and a case can be made that a C# or Java-style language (or plain-jane C++ heavy on standard library usage) is easier to write and maintain. What I'm saying is that 90% or more of your game should be optimized for maintainability, rather than performance, so you can't use that as a metric for saying C++ is the best choice.

Share this post


Link to post
Share on other sites

I think when people advocate not using C++ its mostly cause in their mind they see examples of bad old C++ they had seen some time ago which were done the C way (sadly even books often do this). If you do it the modern C++ way there is probably not much difference in the difficulty level to other languages, but you still have the option of doing some other things if needed for optimization later.

Other than that you would just have to download some library _of_your_choice_ yourself and then for example #include "SFML.h", instead of hoping you get what you want when doing import java.awt.*; .

Share this post


Link to post
Share on other sites

To put things in simple terms I guess... It's not the language you choose, It's the language you are best at. For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better. It's all about coding neatly and efficiently. I know a bit of java and a bit of C++. I find that I am much better at C++ and that I get much better results with my programs in C++ rather than Java. That is just me, that doesn't mean you should not learn java and pick up on C++ . You've got to explore a bit, see what suits you. And if your looking into getting games your going to have to know multiple languages anyway. So for your first language, choose the easiest for you so you can get your feet wet. Every language has its ups and downs.

Edited by demongunsman

Share this post


Link to post
Share on other sites



There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;)

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.
I did specifically say runtime (after all, most software is distributed in text form on UNIX). Though in some of the later specs of OpenGL, apparently you can use compiled (native) code rather than compiling it up from source at runtime.

Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.
For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better
Except that C compilers (especially optimizing ones) *do* produce better ASM than a human (if asked to with -S in gcc). Whereas C# simply runs ontop of another (large) layer of software so can only ever be slower. It doesn't bring anything to the table speed wise. The only thing it (ahem.. Java) brought to the table was a (flawed) non-deterministic memory management system.

You can create fast games with vm languages... Just not as fast as native code... obviously Edited by Karsten_

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357766574' post='5019631']
You can create fast games with vm languages... Just not as fast as native code... obviously[/quote]

Not so obviously.

 

There is no real evidence to suggest that JIT compilers are necessarily any slower than AOT (ahead-of-time) compilers. Most current implementations are slower, but they have been steadily gaining ground over the past few years, and in many areas approaching the speed of native code.

 

In addition, several JIT languages also provide an AOT option (for example, Mono's AOT compiler, or pretty much anything targeting LLVM), which renders moot the entire debate.

Share this post


Link to post
Share on other sites
Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.
If you do an offline shader compile the compiler will output bytecode and so will the CreateShader functions in D3D and this is also true for CG(I don't know enough about GL to comment on it). The shader assembly spit out by these compilers is intermediate code and is run in a JIT fashion, although the driver chaches the resulting commands for future use. That compiled shader code looks like ASM doesn't mean it is directly related to it like normal asm is to a CPU's ISA.
It's up to the driver to take this intermediate shader asm and transform that in to command buffer commands.
It's also this intermediate code that the offline HLSL/CG shader compilers store in binary object files which you can quickly load from disc. Edited by NightCreature83

Share this post


Link to post
Share on other sites

Java's VM is very efficient and has very little noticeable difference in speed from C++. Since it is "higher level" than C++, it may prove to be a better development path for many as it can seriously speed up development time. On the other hand, if you use a library such as SDL or SFML paired with C++ you can harness the speed and the rapid development.

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357766574' post='5019631']
You can create fast games with vm languages... Just not as fast as native code... obviously
[/quote]

 

Fine, so how large is the gap between games written in vm languages and native-code languages? Because if is small, why bother making games using relative complex languages like C++ (as an example of native-code language) ?

Share this post


Link to post
Share on other sites

C++ is dominant for two reasons, and two reasons only:

 

1. Investment. A lot of time has gone into writing C++ code, so it has inertia. The same thing held true of C in years past, and assembly in the era before that.

 

2. Vendor lock. Most platforms for games only support C/C++ and maybe a couple other languages peripherally. The vast bulk of the game market "requires" C++ development because the vendors don't offer good support for any alternatives. This is slowly changing, but a lot of it goes back to a vicious cycle with point #1.

 

 

C++ is not a good language. It isn't even a decent language, for the most part. It's old, crufty, ugly, broken, and woefully behind the times (although C++11 is a good forward step). It is absolutely not succeeding on its inherent merits these days.

 

More people are leaving C++ for game development, and with good reason. It's already a non-starter on Android and iOS, for instance; it's less of a thing in AAA PC games now (see C# and others gaining ground); and sooner or later the console providers will get a clue and start offering other options as well.

 

 

All the wishy-washy nonsense about performance and low-level access and blah blah blah is just academic wankery. Maybe 2% of games in the world need the kind of speed difference that C++ offers, and I'm not even convinced that there aren't better tools than C++ for that 2%. The truth is boiled down to inertia and vendor lock, period.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement