Linux - Native or via Wine

[sobek]

A major game developer is currently working on bringing their titles to Linux platform. We may also guess the future titles will be built as multi-platform from the ground up. I think it bears some significance ;)

 

Ok, i didn't see that they were porting source to linux, i thought it was just the DRM. Well, yes, that is a big deal, but it won't change anything for DCS, unfortunately.

[Rhinox]

Ok, i didn't see that they were porting source to linux, i thought it was just the DRM. Well, yes, that is a big deal, but it won't change anything for DCS, unfortunately.

AFAIK DCS uses directx as gfx-api. This makes portability (I mean true, not wine/cedega) much more difficult compared to opengl which was (and maybe still is) used and supported extensively by Valve. Gabe Newell was for some time strong supporter of open standards and highly critical towards M$-proprietary directx api. Things have changed a little and opengl is somehow loosing ground in games-development...

[Moa]

I didn't read the whole thread but some post got me wondering if there is anyone here who has done some cross platform development and still thinks it is easy. First of all, I am an Linux developer and have used it almost elusively for the last 13 years. But I still use Windows for gaming. When porting a program to Linux you face a lot of challenges:

 

I've been working on a cross-platform flight simulator (only for a couple of months). If you work in C++ it'll kill you. You need a single cross-platform codebase or it is a very large mountain to climb.

 

I'm working in Java and using a lot of the existing libraries to handle the cross-platform issues, such as JoGL (cross-platform OpenGL graphics), JOAL (cross-platform sound), JInput (cross-platform input) etc etc. If you do cross-platform in Java it is easy, in fact, far easier than cross-platform in any other programming language (it was designed to be "write once, run anywhere" and if you know what you are doing it can pretty much do this except for platforms closed to Java for selfish vendor business reasons (Xbox360, iOS).

 

With the correct libraries embedded in the executable Java 'JAR' the same binary runs on Mac and Windows (it should work flawlessly on Linux, but I haven't tried yet, but the fact it works on Mac pretty much means it should work great on Linux).

 

The rendering engine (again, still a work in progress) runs very nicely both on my 2009 MacBook Pro's older Nvidia 9600 GT and on the much faster Radeon 5900 on my Windows 7 box as well. Since nearly all the rendering is on the GPU using Vertex Buffer Objects it runs very nicely with the rest of the system being multi-threaded Java.

 

Here are some videos to show the what is possible if you are able to start with a clean cross-platform architecture (and don't make the mistake of choosing the single-platform .NET instead of Java):

 

I've taken off the canopies so you can see a little bit of detail into the cockpit:

 

F-14D SuperTomcat (in Bombcat configuration)

 

F-16C Block52

 

 

F/A-18E SuperHornet

 

 

Some of the videos got some stutter and blur on encoding, about half-way through the re-encoding gets sorted out and they look a bit better.

 

Anyway cross-platform, single source base and high performance *is possible*, I hope my videos give some evidence for this.

 

ps. yeah, OpenGL support can be crap in Linux for any video card newer than 6 months old. It is the hardware vendor's fault, not that of the Linux Kernel developers. Hopefully this will change as more games for Linux come out and pressure the hardware guys (eg the Steam initiatives).

Edited April 26, 2012 by Moa
youtube links

[Moa]

AFAIK DCS uses directx as gfx-api. This makes portability (I mean true, not wine/cedega) much more difficult compared to opengl which was (and maybe still is) used and supported extensively by Valve. Gabe Newell was for some time strong supporter of open standards and highly critical towards M$-proprietary directx api. Things have changed a little and opengl is somehow loosing ground in games-development...

 

Actually, Windows and Xbox are the only places where DirectX is used. On the vast majority of mobile and embedded devices (of which there are far more than mere desktops) it is OpenGL (specifically OpenGL ES). For commercial systems (eg real aviation) it is (specially certified) OpenGL. For 3D on the web the WebGL standard has emerged and is gaining support (WebGL is based on OpenGL).

 

Really the only reason DirectX exists is Microsoft's clever strategy to keep you on Windows. How many people would stay on Windows if not for the games (eg. all the posts that say they only use Windows for games). DirectX is not even technically superior to OpenGL (DirectX was worse than OpenGL for many years, and then got slightly better as OpenGL stagnated thanks to SGI, now OpenGL is moving ahead again - with multi-vendor support and cross-platform being amongst OpenGL's great strengths).

 

Although these days few game developers choose OpenGL or DirectX directly. They usually work to a game engine rather than go for the lower level rendering library.

Edited April 26, 2012 by Moa

[winz]

I've been working on a cross-platform flight simulator (only for a couple of months). If you work in C++ it'll kill you. You need a single cross-platform codebase or it is a very large mountain to climb.

Well, that's the problem. You kinda have to use C++ for a high-performance title (that DCS is), because it's faster then Java (and .NET for that matter as well).

A developer will trade all the nice things you get with Java for a few FPS and lower ram requirement.

Java might be fine for a little home brew project, but for a big AAA title it's still a no-no.

 

The only mainstream game written in a managed language that comes into my mind is Magicka and it's performance is miserable considering the basic game engine and not so complex graphic.

[c0ff]

X-Plane case: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/

 

"Amongst desktop, maybe half and half Mac and Windows, with totally negligible Linux… like less than 2%".

[Moa]

X-Plane case: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/

 

"Amongst desktop, maybe half and half Mac and Windows, with totally negligible Linux… like less than 2%".

 

True. Linux on the desktop is tiny. Mac is not negligible. Tablets are not negligible. If your software works on Windows and Mac making it work on Linux is not that hard (in fact, it is a good test if your software is truly portable). Plus, the several million Linux desktops out there have a population of users that is more likely to use your software than the average population of Windows users. If you have good cross-platform software then the extra Linux users are just extra profit, not extra cost.

 

However, for servers, Linux is the king. Just because you can't see Linux on the desktop doesn't mean it isn't running everywhere else. Every email you send outside your organization is almost certainly handled by Linux somewhere along the line; every time you use online banking, or the Domain Name System, or interact with your government, or with any Google service - you are relying on a Linux server somewhere that quietly does its job cheaply and without fuss.

 

Supporting Linux is not really for the client. You want to be able to run your dedicated server software on it.

Edited April 26, 2012 by Moa

[Moa]

Well, that's the problem. You kinda have to use C++ for a high-performance title (that DCS is), because it's faster then Java (and .NET for that matter as well).

A developer will trade all the nice things you get with Java for a few FPS and lower ram requirement.

Java might be fine for a little home brew project, but for a big AAA title it's still a no-no.

 

The only mainstream game written in a managed language that comes into my mind is Magicka and it's performance is miserable considering the basic game engine and not so complex graphic.

 

Lol. In many cases Java is much faster than C++, due to the ability of the Hotspot compiler to make run-time optimisations that the static C++ compiler cannot. Statements that "C++ is faster than Java" come from non-developers that read half-decade out of date articles.

 

Plus, with Java it is *very* much easier to use multi-threading and resources in a multi-threading environment. That more than outweighs any supposed micro-optimisation benefit from C++/inline assembly.

 

Finally, what actually matters is how efficiently you can use your GPU, as that is the real constraint to such software. C++ and Java (or just about any other language) are tied here - which is where the productivity benefits of Java really come in (after doing a lot of C++ professionally since the early 90s I'm never going back to it if I can help it - it is just so slow to develop for, doesn't actually run any faster than Java in practice, and has terribly bad tools compared to things like the fantastic, free JVisualVM, Junit, Hudson, Ant, Eclipse etc etc).

 

So, it seems to me you believe C++ is faster because you read it in some article somewhere some time in the past. Please let me assure you is not true today, and C++'s development time is *very* much slower (which is the thing that actually matters on bigger projects, such as a flight sim).

[c0ff]

C++ is capable of manual memory management, and Java is not. With current CPUs being cache-friendly matters.

C++ is capable of SIMD optimisations, and Java is not. Etc. etc.

 

Anyway, if you have a huge existing codebase which actually is one of your main assets (your developers is the other one), it does not matter if some other technology is marginally faster.

[winz]

Lol. In many cases Java is much faster than C++, due to the ability of the Hotspot compiler to make run-time optimisations that the static C++ compiler cannot. Statements that "C++ is faster than Java" come from non-developers that read half-decade out of date articles.

Several years old, riiight - http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php

You cannot use hotspot JVM on a game, because you don't have the time to gather statistics on what part should be compiled/optimized and what parts are fine left interpreted. You have to compile all executed code, because interpretation is much slower and would lead to stutters and performance issues.

And I have no reason to believe that static compiled code is more effective in Java then in C++.

+JVM adds overhead no question about that.

+Native <-> managed code execution is another overhead. You have another layer in which you have to convert everything from unmanaged low lvl to managed objects + transfer all function calls, are you really going to convice me that this doesn't decrease performance.

C++ allows you to do low lvl stuff Java will not.

 

Plus, with Java it is *very* much easier to use multi-threading and resources in a multi-threading environment. That more than outweighs any supposed micro-optimisation benefit from C++/inline assembly.

No, it doesn't outweights. It's easier, faster, more effective to develop for java, but a skilled C++ developer will have no problem with multithreading. The main difficulties in C++ lies somewhere else then multithreading. Multithreading using libaries is a 2 line matter in C++, synchronization is a little more complicated then in Java, but still managable without problems. The main problem of C++ is that a programmer has to know its ins and outs before he can effective with it on a high level. Blowing your foot of in C++ is stupidly easy. And memory managament is a mess.

 

Finally, what actually matters is how efficiently you can use your GPU, as that is the real constraint to such software.

If you put another layer between you and GPU, then you're going to use it less effectively.

 

So, it seems to me you believe C++ is faster because you read it in some article somewhere some time in the past. Please let me assure you is not true today, and C++'s development time is *very* much slower (which is the thing that actually matters on bigger projects, such as a flight sim).

My believe that C++ is faster is based on my personal experience from working as developer for several years.

 

Let's assume that my previous experience is all rubbish and let me ask one simple question - If Java (and managed languages in general) are so great for game development, why is nobody using them? In the end, it's much much much more effective to code in java then in C++, and developers would be stupid to not to use it if it would be really an option.

Edited April 26, 2012 by winz

[Haggart]

Aaaaand because it depends on about 4,5mio different variables if you Java applet is running exactly like it's supposed to be, especially depending on the air pressure over northern alaska and the stepcount of a specific antilope in south africa.

Java is sure nice for "normal" things, because you've platform compatibility, but as winz said, the lower you go, the more performance you CAN have - if you have competent dev's, down to the level of machine code assemblers. In Java it's easier to achieve higher base performance because of many automizations done by the VM, code restructorization, etc, and in many cases of bad-shaped code (and most coded java software is just a big mess), the gains of automatic automization are taking over the loss through the translation in the VM. If you do it right and abandon that level, you can however get much greater results, especially in processing-intensive applications like graphics. And because of the natural misshaping of code (because very few programmers actually recognize the necessary beautifulness of code) and necessaty for debugging, performance optimization by measurements in the VM etc, statements like the "C++ dev time is slower" come to surface.

 

It's all about love (to beautiful code, in this case, and knowledge).

[ALDEGA]

and most coded java software is just a big mess

Lotus Domino/Notes comes to mind ...

[Moa]

C++ is capable of manual memory management, and Java is not. With current CPUs being cache-friendly matters.

C++ is capable of SIMD optimisations, and Java is not. Etc. etc.

The manual memory management of C++ is a complete curse when it comes to managing shared resources under multi-threading. Liberal use of multi-threading will give you a far greater boost than SIMD can (although you can also reach down to the native level in Java to do SIMD if you really had to, and the JNA library makes this fairly painless [compared to the old JNI way]).

 

Anyway, if you have a huge existing codebase which actually is one of your main assets (your developers is the other one), it does not matter if some other technology is marginally faster.

 

Absolutely true. I meant to mention this but forgot. Please don't take my suggestions as criticism of the ED series. The mass of code you already have is a very significant factor in extending an existing product.

 

What I was trying to point out is that C++ for *new* 'green fields' projects may not be the best choice anymore. I hoped my videos would lend weight to this argument, to show it is possible to get good performance from more productive languages (Java in my case) since exploiting the GPU fully makes more of a difference than any small language-level optimizations (IMHO). I also hope to make the slight point that .NET is not a good choice either (although used in IL-2 Cliffs of Dover) since it is not truly cross-platform.

[Moa]

Let's assume that my previous experience is all rubbish and let me ask one simple question - If Java (and managed languages in general) are so great for game development, why is nobody using them? In the end, it's much much much more effective to code in java then in C++, and developers would be stupid to not to use it if it would be really an option.

 

The original IL-2: Sturmovik was written in an old version of Java with C++ for some performance critical stuff (necessary a decade ago, no longer necessary). One cool thing is if you happened to have a newer JVM on your machine than it would run faster.

 

Minecraft is written in Java. This game has been a great commercial success for the developer. How many people complain about its performance?

 

Jake is a port for Quake to Java OpenGL. Runs pretty damn fast if you ask me.

 

So yes, commercially successful games are written in Java. Just as a good C++ programmer can write a multi-threaded program a good Java developer can write a performant program (but in much less time - which means it is more likely to get delivered before being abandoned, which is the true threat to commercial and indie software projects alike).

 

It is good you have some years developing. I have past two decades, with all of that doing C and C++ but have switched to Java mostly for the last 7 years.

 

One problem I have noticed with C++ developers with a few years under their belt start getting obsessed with micro-optimizations (and benchmarks) rather than seeing the Big Picture - which is it is no good if some loop is 2% faster but you are unable to be massively multi-threaded because you can't synchronize resources properly or easily (which also likely means you either ship real late [costly!], or you ship with bugs that crash your program). In java.util.concurrent kicks ass (Doug Lea is a genius!)

 

Java does use more memory for small programs that C++. For large programs the difference is negligible. With RAM so capacious and cheap these days I consider this a non-issue for my own simulator. I'm going to use every gigabyte I can get my hands on (which allows all sorts of speed ups).

 

With regard to the adds an "extra layer above the GPU" comment. This is utter higwash. In fact, it shows you are not familiar with modern GPU programming. Using a Vertex Buffer Object from JoGL is no different at runtime than using it from C++, except of course the associated texture management is far easier with JoGL.

 

The reason people use C++ is because of the reason c0ff gave, the developers already have skills, tools and codebases that use that language. Those development shops came from a time where it looked like Microsoft was going to dominate every space of computing. That phase has come and gone, just as other trends will come and go. Re-writing your software investment for each new platform is very expensive, so people don't. Instead they either miss out on new market opportunities (since they are stuck with one platform) or they spend a great deal of effort and expense to try to adapt to other platforms (and cross-platform is the topic of this thread, after all). My comments in this thread try to point out that you don't have to be hampered by only these two options - if you have the luxury of starting with more modern tech and a clean slate.

 

People also choose C++ in the past because up until Java 6 to get good performance out of Java on the desktop required a fair bit of effort. That is past history (although big projects have long lead times, so decisions made years ago still affect technology and tool choices today).

 

So, I have tried to show the benefits of avoiding platform lock-in by choosing a technology that makes it easy to avoid it. I have demonstrated that a Java OpenGL rendering engine can produce very nice hardware-accelerated images on modest hardware, and do it in a cross-platform way (I had a single codebase and it was *zero* effort to get cross-platform, I just had to run my automated tests on each platform to ensure everything was hunky dory).

 

So, if you want to believe that C++ is still l33t then by all means please do. I also used to a decade ago when immersed in C++ but know I know better. Meanwhile, I'll be elsewhere churning out software in faster time that is already cross-platform (again, the point of this thread), and is fast enough that users don't even know the difference (except if I tell them).

Edited April 26, 2012 by Moa

[Nobody96]

I'm working in Java and using a lot of the existing libraries to handle the cross-platform issues...

 

That is exactly what I was talking about :-) If you plan your code cross-platform beforehand, there are many possibilities. Doing it afterwards is a mess. I use Java almost exclusively because you can develop on Linux and sell it afterwards as a Windows application. But I also believe that you can develop your code platform independent in any language. Maybe not as easy as in Java, but you sure can or else there wouldn't be any reason for Qt.

 

BTW: I used JOGL at the university and IMHO you need at least some C++ OpenGL experience to properly use it. Sadly though I don't have any...

 

so long

Mathias

 

P.S.: If Java is slower than C++, why they used it to develop Apache Hadoop?

Edited April 26, 2012 by Nobody96

[xhaos]

P.S.: If Java is slower than C++, why they used it to develop Apache Hadoop?

 

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model.

there you have it written between the lines, multiplatform.

I am going through my second decade as a developer having worked on both C++ and on Java almost equally. And its my personal expirience that just as an organization will ask you to develop in C++ because all their codebase is there, programmers will also boost the appeal of the language they are using just because they already have invested so much time and effort in mastering it and its a nightmare to pay the emotional cost to "re learn".

Yes I know that you don't restart from scratch, but you do loose some years of experience when you go to a new language just because you can't use any more the tricks and libraries you got to know so well in the past.

 

Just my 2 cents.

[Bucic]

Slightly OT:

Oh joy ;)

NVIDIA Loses Huge GPU Order Due To Linux Blob

http://www.phoronix.com/scan.php?page=news_item&px=MTEyNTE

[samirpiccolotto]

M$ ownd

 

http://blogs.valvesoftware.com/linux/

 

Cmon DCS! Plz! :helpsmilie: