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

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?

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

[quote name='shadowomf' timestamp='1357942757' post='5020488']
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.[/quote]

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)

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.

[quote name='swiftcoder' timestamp='1357943745' post='5020496']
(Hint: quite a few. Although Steam/Origin seem to be fairly immune to this problem)
[/quote]

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.

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)

[quote name='simast' timestamp='1357946644' post='5020520']

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

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