52 replies to this topic

[swiftcoder]

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

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.

[NightCreature83]

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, 09 January 2013 - 04:55 PM.

[minibutmany]

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.

[nimrodson]

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

 

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) ?

[ApochPiQ]

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.

[Karsten_]

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.

C and Assembly are still around and are still as strong as ever. These types of languages don't disappear or get swayed by trends.

2. Vendor lock. Most platforms for games only support C/C++ and maybe a couple other languages peripherally.

In practice it is the other way. Everyone makes libraries in C/C++ so they can be consumed by C# or Java developers. Whereas it simply cannot work the other way. Standard Java cannot use C# libraries. Standard C# cannot use Java libraries. And yet they can all use C/C++ libraries. Standard C++ (because of it's powerful low level functionality) can just about use C# libraries if you embed a mono runtime in it.. but not many people are going to do that.

Also, which Vendor is it that is trying to lock you in with C++? It is perhaps an example of one of the few languages which dont have a single company governing it's standard. Unlike Java or C#.

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.

It has a lot of legacy cruft, I agree (like OpenGL I guess) but when a successful language has been around as long as C++, it can't be helped. The biggest thing for me though is RAII. It is simply missing in all other languages but Ada and is crucial if we have exceptions. C# stuff like LINQ.. I simply couldnt care less about for gamesdev.

More people are leaving C++ for game development, and with good reason.

Not really. Admittedly Gamedev.net does has a large presence of managed language fans, and there are reasons for this but as you know, in the commercial world (no indie crap or vendor lockin to products such as XNA and Unity) C++ is the only language quite frankly.
As for Android and iOS... It is simple, all the commercial games (especially ports) from AAA studios use C++ (with small Java/Obj-C shims) and all the hobby / indie developers use MonoTouch or the specific platform's lockin languages.

All the wishy-washy nonsense about performance and low-level access and blah blah blah

I agree. Especially since this isn't so much about the language but the platform. DotGNU (native C#) would beat C++.NET hands down in speed.

[ApochPiQ]

C and Assembly are still around and are still as strong as ever. These types of languages don't disappear or get swayed by trends.

 
This is totally untrue.
 
I was programming games 15 years ago. C and assembly were far more pervasive then than now. I haven't written any heavy-duty ASM in years but it used to be a regular part of rolling any major game product out the door.
 
Yes, they are "around" but "strong as ever" is patently false.
 

In practice it is the other way. Everyone makes libraries in C/C++ so they can be consumed by C# or Java developers. Whereas it simply cannot work the other way. Standard Java cannot use C# libraries. Standard C# cannot use Java libraries. And yet they can all use C/C++ libraries. Standard C++ (because of it's powerful low level functionality) can just about use C# libraries if you embed a mono runtime in it.. but not many people are going to do that.

Also, which Vendor is it that is trying to lock you in with C++? It is perhaps an example of one of the few languages which dont have a single company governing it's standard. Unlike Java or C#.

You've never shipped a console game, have you? ;-)

It has a lot of legacy cruft, I agree (like OpenGL I guess) but when a successful language has been around as long as C++, it can't be helped. The biggest thing for me though is RAII. It is simply missing in all other languages but Ada and is crucial if we have exceptions. C# stuff like LINQ.. I simply couldnt care less about for gamesdev.

RAII is far from "crucial" in managed languages, because of garbage collection and other lifetime management schemes. But it somewhat exists in C# (IDisposable and using clauses come to mind).

Not really. Admittedly Gamedev.net does has a large presence of managed language fans, and there are reasons for this but as you know, in the commercial world (no indie crap or vendor lockin to products such as XNA and Unity) C++ is the only language quite frankly.

Where are you getting your "data" here? I go to GDC every year, I talk to dozens of professional game developers from several different studios, and I follow the trends in language adoption for personal reasons quite closely. C++ is losing ground and fast. Hell, most games ship a C++ core and a heavily non-C++ implementation of all their peripheral logic. People are dying to put a bullet in the head of that language.

See also Go and Rust. There is major investment from major commercial entities on killing C++. C++ is used for the two reasons I provided in the AAA space, and nothing else.

As for Android and iOS... It is simple, all the commercial games (especially ports) from AAA studios use C++ (with small Java/Obj-C shims) and all the hobby / indie developers use MonoTouch or the specific platform's lockin languages.

Not true. Go do your homework on what languages are used in most games. C++ is the shim language more often than not.

[spiralseven]

I will only use compiled languages for games, I dont want to have to install an RTE just to run my program. 

[ApochPiQ]

I will only use compiled languages for games, I dont want to have to install an RTE just to run my program. 

C++ has a runtime library. It may or may not be linked statically to your program, so you might be reliant on more of a runtime than you think.


In general, avoiding runtimes is probably the least reasonable excuse for using C++ IMHO, because the good ones are either trivial to install or ubiquitous already anyways.

[spiralseven]

I see. Thank you for the insight

[Hodgman]

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.

Shaders are the perfect analogy here -- they're some of the most performance critical code in a modern game, and yet are written in a "JIT" language that follows the same pattern as C# code.

 

 

In GL, you can't pre-compile them (except for the newest GL spec, which allows you to cache the intermediate version for the current GPU only, so you still need to distribute the GLSL source to each user and parse it at least once for their GPU/driver combo), and in D3D you can precompile them to an intermediate assembly format. C#/Java/Python/etc are also pre-compiled to an intermediate assembly format! This pre-compilation step can perform optimisations and greatly reduce the workload on the JIT compiler.

At runtime, this intermediate (shader/C#/Java) assembly code is then JITed to real machine code on demand.

 

However, this JITing can cause spikes in your frame-times, so you need to be able to control when it happens. With shaders that's pretty straightforward (in D3D you tell the runtime to compile it, and in GL you do the same but also draw an off-screen triangle using the shader to force it to actually do what you asked...), but I'm not sure if it's controllable in C#/Java, so that would be my only concern (not the final speed of the JITed code).

Edited by Hodgman, 09 January 2013 - 09:46 PM.

[Aardvajk]

You haven't learned programming until you are at the hardware level C/C++ allows you to be at.

 

What on earth makes you think working with C++ places you at the hardware level?

[jms bc]

Yes, you can write a fast game without c++.

[tanzanite7]

Yes, you can write a game faster without c++. ;)

Did not notice anyone mentioning it and the riming with the last post just begged for it. In short, getting stuff done in a reasonable time-frame is worth to be considered. The extra time might allow you to try other - better - algorithms also, which is where most of the performance improvements lie.

Edited by tanzanite7, 11 January 2013 - 01:44 PM.

[shadowomf]

C++ has a runtime library. It may or may not be linked statically to your program, so you might be reliant on more of a runtime than you think.

In general, avoiding runtimes is probably the least reasonable excuse for using C++ IMHO, because the good ones are either trivial to install or ubiquitous already anyways.

You are overestimating what the usual computer user can or cannot do.

If you expect the latest Java RTE to be available, well don't expect many to be able run your software without any problems. Problems you might have to fix which can cost a company money, technical support doesn't come free.

 

Besides there are also thoose that can install runtime X but aren't motivated. For example I do rarely install any Java related updates, there is just no software that I do use regulary which requires it.

And whenever there is Java software that I would like to use I think twice, because there is probably some smaller tool that doesn't expect me to perform more than a copy&paste setup, so basically no reason for me to waste my time with it.

 

I do however have python, lua, tcl, javascript, c, c++, asm, ... development systems installed and thus the runtimes. Why because I do use them? I know they aren't just some crap wasting my hdd space. f you want to sell me something, you not only have to sell me your game, no, basically you do also have to sell me the huge dependency you are shipping with.

 

In C++ you can either add the runtime too your executable or don't link to it at all. So if you want something really small or really simple too install (copy&paste) it's probably one of the best choices.

[swiftcoder]

In C++ you can either add the runtime too your executable or don't link to it at all. So if you want something really small or really simple too install (copy&paste) it's probably one of the best choices.

Except that isn't really true in practice. How many games fail miserably if you don't have the right MSVC Redistributable package installed?

 

(Hint: quite a few. Although Steam/Origin seem to be fairly immune to this problem)

[Washu]

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

Its important to clarify this point...

 

Eve is not written in C++. It is written in PYTHON with some core components written in C++, either for speed or as an interface to the operating system (their IOCP module which exposes IOCP to stackless python). The core of the game is in Python, not the other way around.

 

That being said, most games that have a scripting language have the "core" of the game written in C++, and then a scripting language layered on top to provide some rapid iteration capabilities.

 

All that being said, there is no reason not to start with a language that is a lot simpler. Such as python with pygl/pygame (or whatever the current frameworks are), or C#/XNA... or any number of other platforms.

 

(Hint: quite a few. Although Steam/Origin seem to be fairly immune to this problem)

That's more because they package it up with the distributable package that you download... as you can see everytime you run a new game and it installs a new MSVCRT package.

Edited by Washu, 11 January 2013 - 05:08 PM.

[SimonForsman]

C++ has a runtime library. It may or may not be linked statically to your program, so you might be reliant on more of a runtime than you think.

In general, avoiding runtimes is probably the least reasonable excuse for using C++ IMHO, because the good ones are either trivial to install or ubiquitous already anyways.

You are overestimating what the usual computer user can or cannot do.
If you expect the latest Java RTE to be available, well don't expect many to be able run your software without any problems. Problems you might have to fix which can cost a company money, technical support doesn't come free.

If you need the latest for your game to work you package that RTE with your installer and have your games installer install the RTE unless a newer version is allready installed. Today almost all AAA games do this for the c++ runtime libraries (Different libraries for each version of Visual Studio) and for DirectX. (Those who don't are doing it wrong) Java, .Net, are no different, If your application needs something then bundle something with your installer or add something as a dependency to your package if you're on Linux, then the system will download and install it automatically if necessary (Which i guess is how Steam handles things as well)

Edited by swiftcoder, 11 January 2013 - 05:24 PM.

[simast]

Comparing a C/C++ run-time to the Java/.NET framework dependency is a bit too much? The game I am working on has around 7 binary lib dependencies.. And they are all statically linked. The EXE has zero dependencies (other than standard Windows DLLs of course). Heck, it does not even need an installer. The only reason why most of the C++ games require MSVCR DLLs installed are because developers are lazy, don't want to build static libraries themselves for their compiler/MT/MD support and just link with the binary DLL packages they can find on the net.

Edited by simast, 11 January 2013 - 05:26 PM.

[swiftcoder]

Comparing a C/C++ run-time to the Java/.NET framework dependency is a bit too much?

It's not that different. You can always package the JRE into an executable, which achieves much the same end.

 

Excelsior produces a nifty-albeit-expensive AOT java compiler to simplify the process, or there are a variety of less-friendly-but-cheaper open-source options (GCJ, LLVM + VMKIT, etc.)