Quake Live Now Available To Linux Gamers

[BlackStar]

Honest answer: 6 months later and it's fucking optimized and working well.

Here is where your falacy lies. You can use those extra 6 months you gained by using a managed language to optimize your code and potentially improve your performance more than 5-10%.

Also note that you can abstract the intensive number crunching parts of an engine into ultra-optimized native dlls. You can then implement the rest of the engine in a managed language with no or miniscule loss in performance.

Not to mention that languages like Ocaml are faster than C/C++ for a large number of tasks.

The right tool for the right job? 100% agreed. As time passes, managed languages are becoming suitable for a wider range of tasks. Other than low-level math, there's little that managed languages cannot do right now - and math isn't an intractable problem either (see Mono.Simd, which was added exactly because game developers requested it.)

Just because you have horse power to spare doesn't mean you have to squander it.

On the contrary, the more power you have the more you can afford to squander. No game or engine is released 100% optimized anymore - hardware is simply evolving too fast for that. Optimize for current gen cards? Your optimizations are obsolete when your game is released two years later. Optimize for next gen cards? Your game runs suboptimally on current hardware.

Use it make it run on systems with less horse power or to implement better game play. Many think this is just a game logic task but boy they are wrong. To do the right game logic you need always low level informations and gathering those requires number crunching to get it done fast.

Better optimized programs are good, noone will argue against that. However, this paragraph doesn't make any sense. What the hell are "low level informations"? Why do you need "number crunching" to gather them?

Also, you still haven't listed any specific hack you have done in your program that you couldn't do in a managed language like C#.

[Dragonlord]

That's all true for static compilers, but I was talking about dynamically generated code, like the Java and .NET runtimes. They can compile the code down to a pseudo-assembly and then compile that further down to binary during runtime after checking out what parts of the code are accessed often or any other type of runtime checking.

JIT simply means to compile code "on demand". This has nothing to do with the compiler knowing about who the code is used. This is like having a static compiler and just compiling the code where needed instead of running it through an interpreter. The end result is though still the same. Both compilers can not figure out the logic behind the code and therefore are unable to do the optimizations a human brain can do by structuring the code properly.

[Dragonlord]

Here is where your falacy lies. You can use those extra 6 months you gained by using a managed language to optimize your code and potentially improve your performance more than 5-10%.

Point denied. You can not optimize beyond the ability of the language. This is a common false idea about managed languages. Each language has barriers and spending more time is not going to get you past the barriers. What you can do is pushing them a bit which is what Java did with JIT. It can do a nice job there but there's just so much a machine can figure out without knowing the higher logic of a program.

Also note that you can abstract the intensive number crunching parts of an engine into ultra-optimized native dlls. You can then implement the rest of the engine in a managed language with no or miniscule loss in performance.

Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself ) and only the logic is in the scripted language.

On the contrary, the more power you have the more you can afford to squander. No game or engine is released 100% optimized anymore - hardware is simply evolving too fast for that. Optimize for current gen cards? Your optimizations are obsolete when your game is released two years later. Optimize for next gen cards? Your game runs suboptimally on current hardware.

Which is why I state over and over again that the current way of designing game engines is totally obsolete and unsuitable for todays hardware. Wasting processing power on unoptimized code or manage language house keeping is not the solution just fighting the symptoms.

Better optimized programs are good, noone will argue against that. However, this paragraph doesn't make any sense. What the hell are "low level informations"? Why do you need "number crunching" to gather them?

Game logic needs to sense/understand the world it acts in. This encompasses things like collision detection and various other forms of sensing and decision making. All of these require to gather fast and efficient a subset of informations from the game world to calculate the result. Obtaining these informations is a number crunching work and requires raw firepower.

[BlackStar]

Point denied. You can not optimize beyond the ability of the language. This is a common false idea about managed languages. Each language has barriers and spending more time is not going to get you past the barriers. What you can do is pushing them a bit which is what Java did with JIT. It can do a nice job there but there's just so much a machine can figure out without knowing the higher logic of a program.

Wrong. You are still thinking on the scale of microoptimizations, where indeed low-level languages shine.

However, you can get much larger benefits by improving your algorithms, writing hardware specific paths (e.g. different shaders for radeons and geforces) or just plain optimizing your level layout and assets.

Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself ) and only the logic is in the scripted language.

An engine contains many more things than number crunching and logic: asset loaders, streaming, tracing, threading, scripting, networking, profiling, debugging. Stuff which hardly benefits from a lower level language.

In fact, the lower-level you go, the harder your life becomes: bugs, memory leaks, unportable code, slower compile times, ABI issues (try exporting C++ code from a dll - nice, huh?). A higher level language will help you write more maintainable code with less bugs and less effort. You can then spend the time you saved optimizing the parts where it actually matters and that's why using a managed language can result in better performance.

Point in case: in my last project, I created 3d world driven through a brain-computer interface. High-end graphics (VSM, SSAO, displacement mapping, stereoscopic rendering). Purely GLSL-driven engine, utilizing OpenGL 3.0 (with 2.1 fallbacks) and running on Windows, Linux and Mac OS X.

Technology? C# and OpenTK. Performance? Scales from laptop graphics to CAVE systems. And you know what the best thing is? This was developed on Linux, but deployed on all platforms - without even recompiling the binaries.

This is what you gain for using a managed language for your engine. It allows you to do things that are otherwise painful or flat out impossible to achieve.

Game logic needs to sense/understand the world it acts in. This encompasses things like collision detection and various other forms of sensing and decision making. All of these require to gather fast and efficient a subset of informations from the game world to calculate the result. Obtaining these informations is a number crunching work and requires raw firepower.

Collision detection = math, which you can move into a reusable, hand-optimized, library. You don't need to code the rest of the engine in the same language as your highly optimized math library. Unless you love writing network logic in assembly, that is. :P

You still haven't given any specific example of memory hacks that you have written in C++ (or whatever language you are using for your engine), but couldn't have implemented in C#.

[mirv]

Anybody who thinks assembly or C will go away....has never done embedded programming.
High end game engines still need that low level kind of programming to get a fast running game. Anyone who thinks otherwise, is simply kidding themselves. You can, however, use scripted languages to help - Unreal is a good example. UnrealScript helped people make some good mods, but it only ran something like 15% of the time (don't quote me on that number - it could well be less or a little bit more). Either way, the bulk of the processing was done in C++.
I will agree that algorithm design is one of the most important features though - no matter what language you use, that is still really important.

[Remco]

Which brings us back to what I say all the time. The number crunching has to be done in C/C++ code ( therefore the game engine itself )

This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.

Hey, that may be a cool idea: a JITed C++ for the web.

<script type="text/c++" src="bla.cpp"></script>

But Js is obviously no C++, JITed or otherwise. That can change though.

[BlackStar]

Anybody who thinks assembly or C will go away....has never done embedded programming.

Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions.

However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.

[BlackStar]

This is possible in any JITed environment with the right features for number crunching. Keep in mind that there is no reason why C++ couldn't be JITed. Whether a language is JITed or not doesn't really say a whole lot.

You mean C++/CLI?

Hey, that may be a cool idea: a JITed C++ for the web.

<script type="text/c++" src="bla.cpp"></script>

Now that's a scary thought!

[mirv]

Neither assembly nor C are going away. There are many, *many* jobs where these are the best tools (or where there's no alternative) and I've programmed enough ARMs, MIPSes and even 8085s (shudders) to have gotten rid of any such delusions.

However, let me ask you a question: do you consider the iPhone or the Android platforms as embedded? Because none of those can be programmed in assembly or C (there's some work for C on the Android, but it's current API uses Java.)

There's little technical reason why C# couldn't run on such environments with a suitable native compiler (obviously without the whole framework). Indeed, both Microsoft and Novell provide versions of their .Net stacks for embedded platforms and there's a lot of developer interest in those. Just check the MonoTouch mailing list (Mono's iPhone stack) or the main mono-dev list - there's definite interest in embedded programming with managed languages, despite the limitations.

Actually, I consider Android and iPhone too powerful to be considered embedded. I do have fond memories of the 68HC11 series from Motorola though (accumulator based) - embedded chips have become much more powerful since then.
I was under the impression that you could use C++ for the iphone (or that the development was based on C++) - wonder what Carmack used with doom there.

[smitty3268]

JIT simply means to compile code "on demand". This has nothing to do with the compiler knowing about who the code is used. This is like having a static compiler and just compiling the code where needed instead of running it through an interpreter. The end result is though still the same. Both compilers can not figure out the logic behind the code and therefore are unable to do the optimizations a human brain can do by structuring the code properly.

You're wrong. Well, you're right that that is the minimum, but wrong that it's the maximum. Wasn't one of the very first Java JIT optimizations to count how often particular methods were called and dynamically inline them when it was often? Even if no current JIT compiler does this, there's absolutely no reason one in the future couldn't, and that was what I was talking about anyway. I have no illusions that the current JS or other compilers are suitable, I'm just saying that someday they could be.