Moa

Well, the famous instance with the F-22 was when it did its first overseas deployment to East Asia via Hawaii. After tanking up with fuel from a KC after leaving Hawaii the Raptors computers all started crashing and rebooting them wouldn't solve the issue. The Raptors had no nav and no radios. Fortunately they could see the tanker in the distance so followed it back to Hickam (right next to Honolulu International). After analysis it turned out that the Raptor software (written in ADA, I believe) was not designed to handle the crossing of the International Date Line. This is just one of those kinks that needed to be sorted out. nb. I believe a substantial amount of the delay in getting the F-35 project finished on time is the difficulty of getting all its C++ to work correctly (the first big use of C++ for a USAF aircraft). Software is hard, reliable software is even harder! Also, lots of older USAF aircraft use a language called 'JOVIAL' for their software (betcha never heard of that language before). See http://en.wikipedia.org/wiki/JOVIAL for more info.

Actually the "Raptor Cough" has nothing do with the On Board Oxygen Generator (OBOG) and everything to do with pulling Gs - technically it is known as "acceleration atelectasis" and AFAIK it can happen to any pilot pulling Gs when on oxygen. It is slightly more prevalent with Raptor pilots but there is the possibility that this is psychosomatic given the stressful nature of the mysterious OBOG issue, rather than a true physical cause. Edit: Here's an interesting article on it (specifically mentions F-15/F-16/A-10 jocks getting it as well) http://findarticles.com/p/articles/mi_m0IBT/is_3_58/ai_84091382/

Have you enabled anti-aliasing (AA) and an-isotropic (AI) filtering on the video card driver as well as in the application? you don't want to do this. 1) Please ensure the driver-level settings (using ATI Catalyst Control Center) are set to "Application controlled" for both anti-aliasing and an-isotropic filtering. 2) Then go to the game settings and use 4x for these settings. Better FPS? 3) If FPS still inadequate decrease the view distance and disable TSAA (which makes translucent objects like your canopy and lights look nice). 4) If the FPS is still not good then get the free GPUZ tool (http://www.techpowerup.com/gpuz/), run it, and look at the sensors page: * Is the GPU running at 100%? * Have you run out of Video RAM (this is a big limitation when you have a HDR, high-resolution, high AA and AI values). Once you run out of Video RAM the card will start swapping and you'll get low frame rates and stuttering - so avoid this by not being too ambitious with settings.

OpenKinect is a work-in-progress intending to support the Kinect on Windows, Linux and Mac. Since the sim I'm working on works on those platforms this is much more interesting to me than TrackIR, and it already has a Java JNA interface (as well as a Java JNI interface), so using it should be very simple. Gotta love Free Software projects :) Please see: http://openkinect.org/wiki/Main_Page

Lol. Own goal! Back on topic. Collision detection with trees might have been too hard in the past but shouldn't be too expensive now (relatively speaking), since CPUs have lots of horsepower these days. You don't have to detect collisions against thousands of trees, you just have to detect against the bounding boxes of hundreds of trees in the vicinity of the aircraft (assuming there is a data structure that segments groups of trees by geographical location - which I'm sure ED must do already since their progressive terrain loading is pretty nice). And when you get very close to a tree you don't need to use bounding boxes anymore. Libraries such as the Open-Source Bullet (bulletphysics.org) can do a lot of the work for you (I'm using JBullet, the Java version).

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

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

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

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.

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.

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

Hi Prinzartus, LockOn/DCS events have been held that have had dozens of people (some with 60+ squadron players for LockOn). There are a couple of things you can do to help with large numbers of players: 1) your 'upload' bandwidth is a big factor in the number of players you can host. You get around 8 players/MB upload speed, but it is a bit better if you have half that. So for a 32 player server you want a 4-8 MB upload speed. When I hosted the A-10C Fly-Ins I could get up to 16 players on a 2 MB/s up connection (which I'm now in the process of upgrading to be much faster). 2) don't run the game server in 3D mode. You get around 10% CPU saving if you leave the server on the F10 map view (the exact amount depends on the CPU). You also get a big saving in CPU if you edit the server's graphics configuration to limit the server frame rate to 10-20 fps. That stops the server wasting time rendering frames (that admins hardly ever look at) and gives it more time to process messages from clients (or run cooler).

Thanks for the screenshot EvilBivol. Personally, I like to see the work in progress. The Mustang project looks like it is shaping up well.

Hmm, still better than any other F-15 model out there.

Thank you Panzertard. I'd just like to say that your English is vastly better than my Norwegian (although my txts after a lot of beer on a Saturday night do resemble norwegian) :) I think these are great moves by ED. I know that it has been planned and on the drawing board for a while, but it is nice to get news that it is actually happening. With Core coming and the new terrain engine in the works its gonna be a new sim (and hopefully more maintainable as new DCS products arrive). It is also great news that the community will be able to help testing (even though the bug reports must make the team tear their hair out). If the stability can get nailed for multi-player then we'll be able to host bigger events again.

Yes, your observations match relatively common experience. One of the greatest strengths of Java is the fact that it is deliberately kept simple. This allows inexperienced developers to construct working software (which is why very many universities offer their first computer science course in Java). This strength is also a weakness. These same people produce software that usually is not very robust or with good performance - but this is mitigated a little as it is still better than if they couldn't produce anything at all. With more time developing they can learn to achieve both. Unfortunately the Java software produced by these people is taken by users as being an indictment on Java itself, when in fact if you know what you are doing Java can be extremely quick. As a simple example, use of Maps for lookups can save you a huge amount of time instead of iterating through arrays. Using StringBuffer for iterative concatenation is around 100x faster than naiive use of String. Over time you learn lots of little things like this that make you code very much faster than an elementary implementation. For me it is not the Java language that matters, it is the portability. I'm fond of C#.NET (which, it turns out, is pretty much an extension of Java) but the lack of portability means it is a non-starter for my purposes (and the open-source Mono project implements the C# language in a portable way but not the most important part, which is the *libraries*). Anyway, I hope when ED finally work their way down the list to a dedicated game server they write it in portable code so we can run it on any spare machines (and virtual machines) we have lying around (or hire).

Short answer is "No". Long answer is that decreased performance has has not been my experience with the all portable programs I have written. Linux/Windows/Solaris have been my main C or C++ targets in the past These days I use Java so extend to Mac too - and the performance gains I get have been using better libraries and algorithms, not micro-optimizations. For example, I'm currently writing my own flight sim and using Vertex Buffer Objects rather than Display Lists (both available in JoGL) is still portable but far outweigh any small C++ optimizations I could have done. Meaning, the algorithms and GPU features available are more important than micro-optimizations (using a little assembler). Similarly, multi-threading in Java is so much easier than C++ that using all the cores on the machine far outweighs any inline-assembly I could have done with C++ (although I can and have used the Java Native Interface and JNA technologies to use native code where I needed to - eg. hardware integration). Finally, I find that not only is portable code (that is, Java) much more productive that C++ (not only due to the language, also due to the huge number of great tools and libraries) I also find that in the case of Java the performance is now better than C++ in many cases where iteration is used (the Sun engineers made the Hotspot just-in-time compiler very, very good). With Java you do have to be careful about what you do to retain good performance - but free tools like JVisualVM (now built in to the JDK) and FindBugs make this pretty easy. With regard to Java gaming there are a few precedents: IL-2 Sturmovik was a mixture of Java, with some performance critical sections in C++ (that was an old engine, I don't think you'd need that native code now, but it is always an option). Minecraft runs pretty well and that is Java. Then I noticed that Bohemia Interactive's Take On Helicopters is getting a Java API and it looks like Armed Assault III will get the same API. From this I deduce that the code itself is either Java or a mix of Java and C++ (I'm speculating here, but I don't think it is an unreasonable guess). I think that the limitation in most multi-threaded games these days is usually the GPU performance not CPU. C++ can be made portable, but from my previous experience I found it much much harder than writing in Java. For multi-threaded networked apps (eg a game server) it is not that hard to write portable code (in either C++ or Java). I hope that answers your question.

Incorrect. Please read my post. I gave approximate uptimes I have seen for various systems. I did not explicitly say Windows or Linux was better. I let you judge that yourself from the uptimes I have observed. In fact, compared to your post Rhinox I defended Windows, the 64-bit versions have sufficient uptime for the current DCS series. Please allow me to also quote what you said earlier: My point was this statement was not correct, VNC was pretty-much developed to be cross-platform. I am a proponent of cross-platform, which is why I suggested VNC, why I posted uptime observations showing all are pretty much good enough for use (although Rhinox you posted anti-Windows statements - thinking the GUI is broken when it is not, perhaps you use poorly written software?). So, please don't project any sensitivities about win-lin debate on to me (yes, you blamed me for attempting to start a win-lin flamewar, which if you re-read my posts you will see is not the case). There are many reasons why a portable game server is desirable. One of them is financial. Here is a case study from the X-Plane developer where he personally made $3.5 million US from porting X-Plane to the iPad with one month's work: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/ My advocacy is, in fact, for "portability". Let the user choose where they want to run the code. Some folks wanna use Linux, plenty want to use Windows. Some will want to use Mac. Aim for portability (it's not that hard!) and the users will choose what suits *them*. I hope this clarifies sufficiently to stop raising the spectre of the win-lin flamewar nonsense, and also stop accusing me of making statements I did not (how about actually reading my posts without injecting your own sensitivities!).

Doesn't the "No Escape Zone" refer to the possibility of outrunning the missile? that is, escaping 'kinematicaly'. Therefore being in the NEZ does not mean you cannot defeat the missile - just you cannot outrun it. On older missiles the best was to defeat it was to cause a great enough crossing angle that it's seeker could not slew fast enough to keep you tracked. This was for older missiles will relatively narrow fields of view and mechanically slewed seekers. I'm not sure whether this still works with newer missiles using imaging focal planes (which I guess have a greater field-of-view, although getting any [classified!] material on this is tough). The other way to defeat a missile is using it's speed against it. That is, even though it can pull many more Gs than the aircraft can because the missile is so fast its turning radius is correspondingly huge. A last-ditch pull-down (using gravity to assist the turn) results in a turning radius that the missile cannot match, thanks to r = v^2/a where turning radius goes as velocity squared. A higher G for the missile can't make up for the squared effect of its higher velocity. The last defense against ground-based missiles is terrain masking. Proper planning and pilot training seems to make this effective.

Technically not built for Windows and ported to Linux. Started out for all platforms (the motivation is so the users could access their Unix servers from their desktops, which were Windows and Linux I think). Please see the original VNC site: http://www.hep.phy.cam.ac.uk/vnc_docs/index.html Wrong. Windows stability has got better - you get uptimes of days or weeks under heavy loads.. Linux is very stable, if you don't have new bling on, you get uptimes of months to years under heavy loads - and yes, I have done this. Mac is pretty stable too (since it is a BSD Unix derivative). Solaris (or Unix) has uptimes of years: I once had a Sparc V machine running Solaris with an uptime of 5 years, and only got rebooted when a memory chip failed. This is why the bigger institutions (banks, government, defence, large internet sites) run Unix/Linux on their servers, although it is invisible to most ordinary users. The 'desktop space' is certainly Windows dominated (we'll ignore the up-and-coming mobiles/iPads/Android(Java on Linux!) tablets that actually are outgrowing desktops), but servers are a mix - which is why people are asking for the ability to run a Linux-based game server. Please note: plenty of other game servers provide Linux server software, and this is usually preferred by admins for stability and performance reasons: eg Counterstrike etc.

The sky colors are likely to be correct accounting for Rayleigh and Mie scattering, rather than the artistic guesses we're used to in existing products. See "Accurate Atmospheric Scattering" on a good approximate that can be done with current GPU shaders: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html

Detailed information for the Typhoon is very tough to come by. That makes it very hard to build a sim for. Unless you know of somewhere that has the flight manual (even for a fee)?

The source code of the Lottu tool is available. It won't help you with the mission file itself. The source does document the FC2 'options' though if you ever need that: http://stallturn.com/wiki/en/lottu The source code is available either as a Netbeans project bundle, or you can take it out of the executable 'JAR' file (which mixes executable compiled classes with the source code so you extract and modify stuff).

The Shuttle software is the only large piece of software known to have zero defects. This is because they tested it for a decade to work out all the kinks. They're not gonna change anything about it now. The programming language used on older USAF aircraft is called 'JOVIAL': http://en.wikipedia.org/wiki/JOVIAL The B1 (using C), F-35 (C++) and F-22 (ADA) are the first USAF aircraft to use regular languages (C/C++/ADA). That's why they had weird teething problems. For example: the 'operational' F-22 software falling over the first time they crossed the International Date line, was nearly a disaster; but is fixed now: http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087/ and many of the delays you hear about in the F-35 program are apparently caused by difficulties getting the software right - large software projects are hard!. More info on the F-22 software here: http://www.f-22raptor.com/af_avionics.php Thanks for the pictures of the Raptor cockpit.

The 'Linux' based system for remote access is called VNC. VNC works on Windows and Macs too. So you don't need your servers to be 'headless' anymore (that is, command-line only).