Especially as Apple removed pbuffer support backward compatibility at the same time. Sure, modern stuff should use FBOs instead, but removing pbuffers busted older stuff (eg. the JoGL Java OpenGL library that I use - fortunately this will be fixed soon).
Do you have a phone or tablet? then OpenGL matters. If you use an operating system other than Windows, then OpenGL matters. If you like movies, then OpenGL matters. If you fly (OpenGL has implementations certified for flight instruments) then OpenGL matters. OpenGL is used for far more than just games, and far more widely than just the personal desktop.
Thank goodness the Khronos Group took over from the old OpenGL Architecture Review Board (ARB). There has been great progress in OpenGL since then, catching up to Direct3D which had come from behind. With this OpenGL we can have this goodness on all desktop (Windows including XP, Linux, Mac, Unix) and mobile computing platforms (iOS, iPad, Android). Personally I'm most looking forward to the improved debug message output - hopefully that should save me some time tearing my hair out trying to resolve my mental model of what is going on vs. the realities/subtleties of GPU programming.
Java is easy to learn for a C++ developer (Java is used in many university level introductory computer science courses) and it very widely used. It is cross-platform and has a vast array of libraries that gets you going across almost all problem domains (networking, hardware accelerated 2D and 3D graphics, web applications [GWT+vaadin are great], embedded systems, Android devices). Oh, and according to the Tiobe Index it has a lot more industry activity than C# (yes, yes, C# is used widely, but it turns out not nearly as much as Java).
What is your point? do you believe that C/C++ is more reliable than Java? have you developed in all three languages for an extended period, if you had you would understand my point, C/C++ are inherently much less reliable languages than Java (C/C++ programs are subject to uninitialized variables, dangling pointers, out-of-array bounds, pointer arithmetic, very weak resource management under multi-threading etc etc). In fact, reliability was one of the reasons that Java was invented (to control smart devices and avoid many of the unreliable constructs of C and C++). In terms of performance, while Java uses a lot of memory (not an issue these days) the performance of code generated by Just-in-Time compilers often out-performs static compilers (since the JIT has real information about what needs to be optimized whereas the ahead-of-time compiler must guess, often incorrectly).
> "if matter is energy and energy is consciousness"
First part is true. Second part is not true (some would classify as "New Age" pseudo-babble). A single photon contains energy, yet you cannot say a photon is conscious in any meaningful way.
Science did not distance itself from God to avoid persecution. Science simply asks, "If I postulate the Universe is like *this*, does that match my observations?". There is no place for the "supernatural" because if such things are observed, verified and repeatable they become "natural".
Now science and morality are separated, but the logical and scientific mind comes to a morality because of the logical social and personal benefits that "moral behavior" results in. Christopher Hitchens was excellent at explaining how the Ten Commandments merely codify the moral behavior of a people, it was not as if the people were amoral before they were handed a divine, dictatorial, unescapable decree. In fact, Hitchens finds the idea that humans would be amoral without such divine laws and contra to observation (humans are innately moral) but actually insults the dignity of humans to assume we are not. He also points out that religion was our first pass at understanding the confusing world, morality, public health etc. It turns out that these days we actually have a lot better understanding of everything. Perhaps it is time to relegate our first attempts (superstition and religion) to items of historical interest and let compassion and reason (you need both) move us forward, since these don't require us to mutilate the genitalia of our children, or kill people who disagree with us, or burn people at the stake, or extract guilt-ridden payments on fear of eternal punishment, or blow ourselves up, or whip ourselves until blood is drawn, or deny ourselves nutrition on certain days, or deny ourselves natural human sexual relations between consenting adults, or take someone else's land, or hide criminal molestors for the sake of our organization, or deny other people AIDs medicine, or deny women the right to determine what to do with their own bodies, or unnatural asceticism, or non-productive mystic contemplation that relies on the generosity of others. These things may separate from religion but it turns out that every religion results in these things happening.
Choosing the best approximation we can get to objective reality avoids the pitfalls of accepting the subjective (which saves you from the hard part of criticizing your own position - which a search for the objective forces you to do on a continuous basis, and this is very healthy). There is no "bias" in choosing the objective over the subjective, it is just that the objective is choosing to see the whole picture rather than squinting and accepting only the picture you want to see, and this makes the pursuit of the objective far more noble and truthful than stopping at a flawed and limited subjective view.
> In the end, though, I think we'll find that a subjective Universe is actually a more intuitive bias.
Of course it is intuitive. It is the conclusion that even a caveman could draw. That does not mean it reflects the reality of the Universe. Now it is true that our objective view of the Universe is not perfect and that objective view is being refined as time goes on, but that does not mean an objective view of things is inferior to the subjective - it just means the objective view seeks to approximate Truth as time goes on, whereas the subjective is content to wallow in its current level of ignorance. Progress has only been made by seeking to discard biases inherent in subjective views and trying to find the objective aspects laying underneath it. The proponents of the objective view fully understand the points made by subjective opponents, it is just that the subjective view has been used in the past and was found to be inferior. Let me say that again, science does not chose the subjective view from a lack of understanding, in fact scientists and philosophers understand the subjective poi
Japan will not get the F-22, since their Naval college leaked details of the Aegis system to China (a Chinese woman married a Japanese man and took a CD that the Japanese had made about Aegis - which they shouldn't have done). The US (Congress?) said that Japan won't get the F-22. On the other hand they put forward that Australia would be offered it (the Aussies are extremely 'tight lipped' with military aircraft details and manuals).
Viper comes from "Colonial Viper" (that is, from Battlestar Galactica - the first one). This was because the advanced nature of the F-16 when it came out lead to comparisons with the starship/fighter. Everyone uses "Viper" apart from official statements from the USAF, who have to use the long name (even though everyone in the USAF itself appears to use the unofficial "Viper").
What this AC has posted is true (dunno why he has been modded to 0). I posted earlier in another part of the thread. Please read the comment http://tech.slashdot.org/comments.pl?sid=3026339&cid=40881293 for a rebuttal of the people who modded the parent's comments down (despite them being factually correct).
Note also that the AK-47 was design to produce volume of fire by barely trained recruits (necessary from the Russian experience when over 80% of their army was killed in 1943 alone). The Western way (weapons and aircraft) is to build maximum performance systems. This require skill to operate and some effort to maintain, but result is *vastly* better performance (eg. the *recent* combat records of Western aircraft+pilots+weapons vs Soviet-design aircraft is incredibly impressive, eg. 1982 in the Bekaa Valley). The M-16 (and M-4) is a fairly unreliable design, as shown in recent US Army tests where alternatives were considered. Just because the inaccurate AK-47 is more reliable than the M-16/M-4 does not mean there are not more accurate *and* reliable Western alternatives out there (although the increase in reliability is not considered worth the expense for the US to replace the M-4 at this time).
The AK-47 has developed a mystique from the uninformed that is doesn't deserve (in part from now out-of-date poor M-16 experiences in Vietnam). The modern M-16A4 and M-4 are much better weapon than the AK-74 (successor to the AK-47). Just ask the insurgents in Falluja about that (hint: you'll need a psychic medium to do that; in fact, the number of headshots the US was able to achieve due to the accurate nature of the weaponry firing at the only exposed part lead to investigations of war crimes [thinking the headshots were executions], it turned out there were no executions simply a very accurate weapon in the hands of very well trained Marines).
The problem with gaming on Linux is really very simple and comes down to a single word: reliability
I have tried many different games on Linux, including buying X-Plane. However I found that the games are even more flaky than driver support (which is now fairly good). IMHO (as a developer) there are several causes of this:
1) Linux developers are still using C and C++. These languages are hard to get large systems right in. Sure you can do it, but it takes a huge amount of effort. nb: I'm developing a game using Java+JoGL+JOAL+JOCL+JInput; The Java language, tools and common techniques help get reliability (and the performance is excellent, especially once you understand how to let the GPU do the heavy lifting).
2) Game developers don't seem to know about the tools and techniques that developers in other areas have adopted to produce reliable systems (eg. test driven development, design by contract etc) that allow even more complex programs to work reliably. Reading the game dev literature they seem to feel they are a breed apart, which lets them continue to use bad software development practices and as a result, produce unreliable code (nb: you can write fast *and* reliable code, they just aren't in the mindset to do this). Examples: the hideous number of basic bugs in Skyrim (as great a game as it is); DCS World and LockOn crash for all sorts of dumb reasons (null pointers, corrupt network data, abstract method invocations, bad config files - they don't seem to check validate inputs at all); IL-2 Cliffs of Dover routinely puts up obfuscated stack traces, which should not happen in a properly tested program.
3) Game developers obsess about speed above everything else. What they never consider is that no-one cares about the frame rate if they are crashing to desktop every 30 minutes.
As a developer who constantly thinks about the reliability of my software I have found several things that are critical for reliability:
A) If you didn't test it then there are probably bugs there. You need automated tests and some measure of test coverage. In well-tested code there are very few non-design bugs in the software.
B) One way well-tested code can fail is if it is given bad input. Validate you input when you get it, and check other preconditions (eg, initialized states). Also validate that all the input is consistent when you use them in combination. It is better to reject bad input before you start processing than discover it halfway through processing and you have an inconsistent state (not all types of programs are database programs that have the luxury of rolling back transactions). This means your program is designed to "fail fast".
C) If you have a well-tested program running with validated input the only other way it can fail is if you run in to environment problems (unreliable connections, out-of-memory, non-existing files etc). If this happens you detect the problem early and fail the operation. Meanwhile your program should revert to the "safe state" it was before the latest operations started. You can then try again or abort the operation. The program will keep running and allow you to report the problem in detail. Dropping out to desktop with not a peep as to why it failed is the sign of a crap design (the only exception is bad kernel-space drivers causing a crash, but most programs can detect errors and report them).
D) If something does go wrong then collect *all* the information you have about the problem and log it (eg. the value of a bad parameter, what the limits of the parameter were supposed to be min/max [you can have a good argument value but bad configured limits]; eg. the full path to the file you were trying to open; eg. what object you were trying to read from the network etc etc). You can't fix a problem you don't have enough information about.
E) Always consider the units you are working with: time can be in miliseconds, years, seconds, days, months; distances in mm, meters, nautical miles. Mi
> Well, I work on near real-time systems. Memory is not so much an issue, but performance is. And VM'd tech (even.NET's C# and C++/CLI) just don't cut it.
"real-time" can mean a lot of things. Meanwhile, Java has RTS (Real-Time Specification for Java) for both soft and hard real-time. Here's another starting point for you: http://en.wikipedia.org/wiki/Real_time_Java
Take a look, you'll see that Java can do hard realtime if you need it (especially since you are not memory constrained). That way you get the goodness of Java (eg. easy XML, expanding collections etc) while still being deterministic and meeting hard real-time requirements. Cool, eh?
Well, it depends on what you are building doesn't it? and who is funding your development project (business-as-usual has a different pace than project work, in my experience).
> No, that's just an advantage of a byte-encoded language since you effectively have the source all the time as a result. And while Eclipse is in many ways superior to even MSVS, it also faulters in many ways as well - e.g. handling C/C++ projects is a PITA to get setup.
Fortunately I've moved on from C++ and only have to use it when interfacing hardware. Given a choice between developing in Java or C++ there is no contest anymore IMHO, unless you are on a severely memory constrained device (getting increasingly rare these days) Java wins for development speed, ease, cross-platform portability, tools, and breadth of modern libraries.
Shame you aren' working in Java. The debugger is first rate in any of the IDEs (you have a choice) and JVisualVM is unparalled - you don' have to do anything special, just attach to any program running in your VM and away you go. Plus, with Java you can use JoGL for write one run anywhere (apart from a few AMD vs Nvidia gotchas) high-performance OpenGL programs, that's what I'm doing and it is awesome to use the same code between Mac, Linux and Windows without having to any porting effort (since the OpenJK, jogamp and jinput guys smooth over all of that away for you).
No wonder you are a posting as an AC. IMHO, there are a lot better tools than Visual Studio on Linux and Unix (JVisualVM, DTrace/strace, various GL profilers).
Probably they changed from immediate moe rendering to Vertex Buffer Objects, Frame Buffer Objects, Pixel Buffer Objects and the like. By using more modern (as in the last decade years) OpenGL constructs you can get awesome performance, since the GPU and video RAM are doing nearly all the work (rather than transferring across from main RAM and have the GPU stall while waiting for the CPU).
Hardware OpenGL has always been faster than DirectX (there were a lot of companies and talented engineers pooling ideas for OpenGL, plus it has been around a while and worked out a lo of kinks). This shouldn't be a surprise. There was a hiatus where DirectX was ahead on features (we'll ignore the OpenGL extensions, and consider Core only). Now OpenGL has feature parity wih DirectX and works on a lot more platforms (which you could take as OpenGL actually having more features) - including OpenGL's superior support for Windows XP.
Actually the F-22s do this to get good at the close-in fight as well as the long-range engagements the USAF prefers (their tactics are based on a long range 'skate' where they launch and extend - using the superior training and situational awareness [via datalinks and AWACS] to beat their opponents).
What is unusual is the 1 vs 1 nature of the engagements. Usually F-22s and F-15s train at 2 or 3 to 1 odds. Occasionally the USAF loses the fights and the opponents always crow about it (eg. the EF/A-18G that beat a Raptor once, the Indians that managed to win a couple of matches against F-15s at Nellis), what is ignored (since it doesn't make sensational news) is all the times the USAF wins. Now it is totally unrealistic for the USAF to win every engagement without losses (no matter what the aircraft) but the general public seems to have the wrong impression and expect the USAF to have a no-loss record (clearly ridiculous). Now the Pentagon has a vastly more realistic expectation and don't expect the 187 Raptors that were built to be nearly enough - which is why the leaked a report in 2008 to try and get more Raptors built:
Now that is 6 Raptors flown from Alaska to Guam and fighting near Taiwan (not mentioned in the linked article, but that was the scenario) vs around one quarter of the Chinese fighter force. While it was marketed as a "loss" (remember, the Pentagon wanted to scare the US public into sensibility and get more Raptors just in case stealth wasn't the advantage they thought).
Regarding the effacy of stealth. Even the pilots of the F-117A flying over Baghdad thought it might not work. It turned out it did. The pilots certainly realised the limitations of stealth http://www.defensemedianetwork.com/stories/gulf-war-20th-black-jet-over-baghdad/
Note that the F-117 lost over Serbia was due to the smarts of the Serbians using a combination of visual (and aural) spotters, guessing attack routes, and using very old radars working at wavebands that the stealth fighter is less optimized against. Stealth is not magic, apparently it merely reduces detection range to around 20% of normal for an aircraft of similar size (for the F-117), or 10% for the F-35 and F-22s (from the front aspect).
Stealth is not a silver bullet. It is still an edge (among other several other edges the USAF has) in modern combat.
>you are talking flight sims which has ALWAYS been a small niche to begin with.
I hope you read the article I sent you to see the actual numbers. half a million sales is a decent number (times $7 per sale in the case of the X-Plane author, or $50 in my case), now work out how much money could be made. Even if I got a couple of thousand sales then I would be very happy, and I know that there is easily that number since I created a pilot statistics system for LockOn: Modern Air Combat and used to see thousands of players each month, with about half of those as new players every month.
> Hell its one of those things if you don't have the right controller they suck and how many people have a flight stick anymore?
Again, you are trying to translate the media's portrayal of the console market into the flight sim market. Almost all of the players I encountered in my stats system had at least a mouse and keyboard (which you can use on my sim) and plenty had a decent joystick and TrackIR, and some had nice rigs like mine (Thrustmaster Warthog HOTAS, TrackIR, multiple Thrustmaster F-16 MFDs, rudder pedals, multiple screens etc). Fortunately I had to do little work to support these on my three platforms (Mac, Linux and Windows). JInput, FreeTrack and linux-tracker handle all devices I have encountered so far.
> BTW you ever thought about a space sim? If you want a flight genre that isn't crowded and which has a pretty damned dedicated community THAT would be the one right there.
Thanks for the suggestion. Yes, I considered this for a long time. I would really love to do a modern version of X-Wing vs Tie Fighter, but up the realism level a little. I couldn't be bothered dealing with the licensing folks at Lucasarts (plus, they have MMOG that cover some of this). It actually turns out that the sci-fi gaming space is already catered for better than modern jet combat. Have you ever looked at Freespace, Vega Strike, StarWraith, Evocron Mercenary, Oolite, Orbiter, Space Engine, Infinity Universe (real nice)? Plus all the existing commercial ones (from Lucasarts etc)? So I consider this space (pun intended:)) fairly well covered.
> The guys in those hardcore flight sims can be so anal retentive they'll bitch if you get the fuel switch in the wrong place on that Huey LOL!
Yeah, there certainly are some crazy wankers out there, amongst all the interesting people. Fortunately I have two things on my side: I've done a lot of homework and have NATOPs flight and weapon manuals for the flyable aircraft I'm working on (plus some gems like the NASA flight and fly-by-wire models for the F-16), and also I don't really care about coverage of the fringes of the community in the sense that I'm writing the sim to meet my needs and hope others will like it (which I'm sure they will). I don't feel the need to compromise the sim in order to 'widen the net' to put food on my table (not tossing, but to give you a perspective Java consulting pays me quite a bit more than most of our Members of Parliament - so even modest sales are just icing on the cake for me).
> Oh and if you are having choppers...ever think about maybe adding the Loach? Everyone seems to put the big slow fat choppers like the HU-1 and the Hind but nobody ever seems to go for the light and nimble attack choppers like the Loach. I got to see the civilian version of one of those in flight and they can practically make those sucker dance, nimble as hell and would probably be a blast in a flying game. It would also be cool if you have the Huey and the Hind if a couple of friends could man the door guns, be awesome for MP to have one guy fly the chopper while a couple of other mount the door 50cal and go to town. Be a good way to give the slower choppers a chance against faster opponents.
You can do this already in Armed Assault II (with AA 3 to be released fairly soon, aparently), and the loach is a a lot of fun (especially if you have a TrackIR then flying it around nap-of-the-earth is awesome). It is a
It shouldn't do, ever since Java 1.6.0 u10 (when they moved all of Java2D to DirectX/OpenGL hardware accelerated rendering) it has been blazing fast. What can happen is that new people don't understand not to block the Event Dispatch Thread with processing - if you avoid this then Java is very responsive as a GUI (since multi-threaded resource sharing is so much easier in Java than C++). For non-GUI processing Java has always been very fast, one of the reasons that Java is currently king of the Enterprise space (which makes it invisible to most desktop users). Coupled with the fact that JVisualVM comes as part of the standard OpenJDK/Oracle development kit (JVisualVM is a fantastic profiler that you can attach to any running JVM) there is simply no excuse for slow Java code (apart from programmers who don't know what the hell they are doing, but then there is an old saying, "You can write bad FORTRAN in any language").
If you're not a developer and been reading articles that Java is slow then you are either reading articles from a decade ago (when C++ did have an edge) or from someone who either hasn't developed on a new JVM (and is parotting the statements of uniformed people) or is new to Java development (and so makes elementary and easily avoided performance mistakes, like not knowing to profile with JVisualVM when performance is critical to the application).
As I pointed out, my experience in writing the jet combat flight simulator is that Java is more than fast enough for that purpose, has excellent development time (thanks to existing libraries and tools), is cross-platform, and is completely free/Free (which means I can share code with others knowing they can build it without having to steal or pay for expensive licenses [or slightly restrictive ones, I'm looking at you XNA]).
> Dude I wish you luck but that's an awful teeny tiny itsy bitsy niche you are aiming for.
Thanks man but do the math. In fact, you don't even have to do that, simply look at how much money Minecraft made - at that is a pretty out-there game too. You see the economics of an indie game are different than that of a AAA title - I have none of the overheads that EA has, and nearly all of revenue is pure profit. I think that is the mistakes that many folks make, they think that only the big houses can make money. Here are some actual numbers from an interview of the X-Plane author:
http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/
Now I'm not targetting iPhone/iPad, but my revenue per unit is nearly a factor of 10 higher (which I know I can get away with, since I'm not entering the target community with no idea - I'm actually been modding the only other product in this genre for a while and paying attention to what that community has been asking for - even if most gamers are completely oblivious to this [but those folks are not my target market, and I don't need them to still be very profitable]).
> But in a way you post validates exactly what my point was, as you had to buy artwork that would automatically put you on the RMS "enemy of freedom!" list for using.
I bought artwork to get a faster time to market (although as an part-time indie dev the time to market is not a critical factor, I make a lot of money in my day job [I don't want to be a tosser, but the fact is that the potential money in this project is nearly all bonus and I have no financial pressures at all to rush it to market]). Now, RMS would say the situation is less than ideal, but it is better that the software works on a Free platform than not at all. Incidentally, I'm considering using a fair chunk of the money I make on the project to commissioning assets that I can release as Free Software (eg Creative Commons), since the money is a nice bonus. I believe I could make a modest living doing this (which you argue is not possible), again since I have very low overheads (unlike big players that must make hundreds of thousands of sales or they can't make back their advances and overheads). Personally I think Free Software is more suited to infrastructure projects where more than on stakeholder can contribute than games, but I still think it is possible to succeed even with games (perhaps not with the same margins and overheads that EA gets, even for their stinkers).
It's 'under the radar' at the moment. You can take that as me being full of b/s if you like, but as an indie/homebrew dev I'd prefer to STFU until very close to release (don't want to promise anything I can't deliver within the next half year). If you've seen or played DCS:Ka-50 or DCS:A-10C then just below that is the quality of product I'm aiming for, but multi-platform (and leveraging all those lovely Java technologies I mentioned, which have saved a huge amount of time - plus all the usual Java goodness like JAXB, JVisualVM etc etc that makes even lil' ol' me much more productive per unit time than someone working on C++).
Sorry I can't give you more info amgo, I intend to reveal a lot at the end of the year. Meanwhile, I'm mid-way through implementing Eric Bruneton and Fabrice Neyret's superb research papers in JoGL/GLSL : check the excellent videos for Proland, http://www.youtube.com/watch?v=2AVh1x-Uqjs, and then just imagine modern multiplayer jets running around there, such as these turbosquid models I licensed:
So, I hope my points about Java + JoGL + JOAL + JoCL + JInput are taken seriously, especially by homebrew/indie game devs that otherwise might be trapped by using XNA when very good free tools are available (I can get less than 1 ms rendering time/1000 fps on an Nvidia 9600 GT mobile on my 2009 MacBook Pro using OpenGL VBOs for the F/A-18 Hornet with around 50k polygons and several textures and a shader for the limb-darkened sun - so Java/JoGL is definitely fast enough for modern games).
Slashdot Mirror
Especially as Apple removed pbuffer support backward compatibility at the same time. Sure, modern stuff should use FBOs instead, but removing pbuffers busted older stuff (eg. the JoGL Java OpenGL library that I use - fortunately this will be fixed soon).
Do you have a phone or tablet? then OpenGL matters. If you use an operating system other than Windows, then OpenGL matters. If you like movies, then OpenGL matters. If you fly (OpenGL has implementations certified for flight instruments) then OpenGL matters. OpenGL is used for far more than just games, and far more widely than just the personal desktop.
Thank goodness the Khronos Group took over from the old OpenGL Architecture Review Board (ARB). There has been great progress in OpenGL since then, catching up to Direct3D which had come from behind. With this OpenGL we can have this goodness on all desktop (Windows including XP, Linux, Mac, Unix) and mobile computing platforms (iOS, iPad, Android). Personally I'm most looking forward to the improved debug message output - hopefully that should save me some time tearing my hair out trying to resolve my mental model of what is going on vs. the realities/subtleties of GPU programming.
Java is easy to learn for a C++ developer (Java is used in many university level introductory computer science courses) and it very widely used. It is cross-platform and has a vast array of libraries that gets you going across almost all problem domains (networking, hardware accelerated 2D and 3D graphics, web applications [GWT+vaadin are great], embedded systems, Android devices). Oh, and according to the Tiobe Index it has a lot more industry activity than C# (yes, yes, C# is used widely, but it turns out not nearly as much as Java).
What is your point? do you believe that C/C++ is more reliable than Java? have you developed in all three languages for an extended period, if you had you would understand my point, C/C++ are inherently much less reliable languages than Java (C/C++ programs are subject to uninitialized variables, dangling pointers, out-of-array bounds, pointer arithmetic, very weak resource management under multi-threading etc etc). In fact, reliability was one of the reasons that Java was invented (to control smart devices and avoid many of the unreliable constructs of C and C++). In terms of performance, while Java uses a lot of memory (not an issue these days) the performance of code generated by Just-in-Time compilers often out-performs static compilers (since the JIT has real information about what needs to be optimized whereas the ahead-of-time compiler must guess, often incorrectly).
> "if matter is energy and energy is consciousness"
First part is true. Second part is not true (some would classify as "New Age" pseudo-babble). A single photon contains energy, yet you cannot say a photon is conscious in any meaningful way.
Science did not distance itself from God to avoid persecution. Science simply asks, "If I postulate the Universe is like *this*, does that match my observations?". There is no place for the "supernatural" because if such things are observed, verified and repeatable they become "natural".
Now science and morality are separated, but the logical and scientific mind comes to a morality because of the logical social and personal benefits that "moral behavior" results in. Christopher Hitchens was excellent at explaining how the Ten Commandments merely codify the moral behavior of a people, it was not as if the people were amoral before they were handed a divine, dictatorial, unescapable decree. In fact, Hitchens finds the idea that humans would be amoral without such divine laws and contra to observation (humans are innately moral) but actually insults the dignity of humans to assume we are not. He also points out that religion was our first pass at understanding the confusing world, morality, public health etc. It turns out that these days we actually have a lot better understanding of everything. Perhaps it is time to relegate our first attempts (superstition and religion) to items of historical interest and let compassion and reason (you need both) move us forward, since these don't require us to mutilate the genitalia of our children, or kill people who disagree with us, or burn people at the stake, or extract guilt-ridden payments on fear of eternal punishment, or blow ourselves up, or whip ourselves until blood is drawn, or deny ourselves nutrition on certain days, or deny ourselves natural human sexual relations between consenting adults, or take someone else's land, or hide criminal molestors for the sake of our organization, or deny other people AIDs medicine, or deny women the right to determine what to do with their own bodies, or unnatural asceticism, or non-productive mystic contemplation that relies on the generosity of others. These things may separate from religion but it turns out that every religion results in these things happening.
Choosing the best approximation we can get to objective reality avoids the pitfalls of accepting the subjective (which saves you from the hard part of criticizing your own position - which a search for the objective forces you to do on a continuous basis, and this is very healthy). There is no "bias" in choosing the objective over the subjective, it is just that the objective is choosing to see the whole picture rather than squinting and accepting only the picture you want to see, and this makes the pursuit of the objective far more noble and truthful than stopping at a flawed and limited subjective view.
> In the end, though, I think we'll find that a subjective Universe is actually a more intuitive bias.
Of course it is intuitive. It is the conclusion that even a caveman could draw. That does not mean it reflects the reality of the Universe. Now it is true that our objective view of the Universe is not perfect and that objective view is being refined as time goes on, but that does not mean an objective view of things is inferior to the subjective - it just means the objective view seeks to approximate Truth as time goes on, whereas the subjective is content to wallow in its current level of ignorance. Progress has only been made by seeking to discard biases inherent in subjective views and trying to find the objective aspects laying underneath it. The proponents of the objective view fully understand the points made by subjective opponents, it is just that the subjective view has been used in the past and was found to be inferior. Let me say that again, science does not chose the subjective view from a lack of understanding, in fact scientists and philosophers understand the subjective poi
Japan will not get the F-22, since their Naval college leaked details of the Aegis system to China (a Chinese woman married a Japanese man and took a CD that the Japanese had made about Aegis - which they shouldn't have done). The US (Congress?) said that Japan won't get the F-22. On the other hand they put forward that Australia would be offered it (the Aussies are extremely 'tight lipped' with military aircraft details and manuals).
Viper comes from "Colonial Viper" (that is, from Battlestar Galactica - the first one). This was because the advanced nature of the F-16 when it came out lead to comparisons with the starship/fighter. Everyone uses "Viper" apart from official statements from the USAF, who have to use the long name (even though everyone in the USAF itself appears to use the unofficial "Viper").
What this AC has posted is true (dunno why he has been modded to 0). I posted earlier in another part of the thread. Please read the comment http://tech.slashdot.org/comments.pl?sid=3026339&cid=40881293 for a rebuttal of the people who modded the parent's comments down (despite them being factually correct).
Note also that the AK-47 was design to produce volume of fire by barely trained recruits (necessary from the Russian experience when over 80% of their army was killed in 1943 alone). The Western way (weapons and aircraft) is to build maximum performance systems. This require skill to operate and some effort to maintain, but result is *vastly* better performance (eg. the *recent* combat records of Western aircraft+pilots+weapons vs Soviet-design aircraft is incredibly impressive, eg. 1982 in the Bekaa Valley). The M-16 (and M-4) is a fairly unreliable design, as shown in recent US Army tests where alternatives were considered. Just because the inaccurate AK-47 is more reliable than the M-16/M-4 does not mean there are not more accurate *and* reliable Western alternatives out there (although the increase in reliability is not considered worth the expense for the US to replace the M-4 at this time).
The AK-47 has developed a mystique from the uninformed that is doesn't deserve (in part from now out-of-date poor M-16 experiences in Vietnam). The modern M-16A4 and M-4 are much better weapon than the AK-74 (successor to the AK-47). Just ask the insurgents in Falluja about that (hint: you'll need a psychic medium to do that; in fact, the number of headshots the US was able to achieve due to the accurate nature of the weaponry firing at the only exposed part lead to investigations of war crimes [thinking the headshots were executions], it turned out there were no executions simply a very accurate weapon in the hands of very well trained Marines).
The problem with gaming on Linux is really very simple and comes down to a single word: reliability
I have tried many different games on Linux, including buying X-Plane. However I found that the games are even more flaky than driver support (which is now fairly good). IMHO (as a developer) there are several causes of this:
As a developer who constantly thinks about the reliability of my software I have found several things that are critical for reliability:
> Well, I work on near real-time systems. Memory is not so much an issue, but performance is. And VM'd tech (even .NET's C# and C++/CLI) just don't cut it.
"real-time" can mean a lot of things. Meanwhile, Java has RTS (Real-Time Specification for Java) for both soft and hard real-time. Here's another starting point for you: http://en.wikipedia.org/wiki/Real_time_Java
Take a look, you'll see that Java can do hard realtime if you need it (especially since you are not memory constrained). That way you get the goodness of Java (eg. easy XML, expanding collections etc) while still being deterministic and meeting hard real-time requirements. Cool, eh?
Well, it depends on what you are building doesn't it? and who is funding your development project (business-as-usual has a different pace than project work, in my experience).
> No, that's just an advantage of a byte-encoded language since you effectively have the source all the time as a result. And while Eclipse is in many ways superior to even MSVS, it also faulters in many ways as well - e.g. handling C/C++ projects is a PITA to get setup.
Fortunately I've moved on from C++ and only have to use it when interfacing hardware. Given a choice between developing in Java or C++ there is no contest anymore IMHO, unless you are on a severely memory constrained device (getting increasingly rare these days) Java wins for development speed, ease, cross-platform portability, tools, and breadth of modern libraries.
Excellent!
Shame you aren' working in Java. The debugger is first rate in any of the IDEs (you have a choice) and JVisualVM is unparalled - you don' have to do anything special, just attach to any program running in your VM and away you go. Plus, with Java you can use JoGL for write one run anywhere (apart from a few AMD vs Nvidia gotchas) high-performance OpenGL programs, that's what I'm doing and it is awesome to use the same code between Mac, Linux and Windows without having to any porting effort (since the OpenJK, jogamp and jinput guys smooth over all of that away for you).
No wonder you are a posting as an AC. IMHO, there are a lot better tools than Visual Studio on Linux and Unix (JVisualVM, DTrace/strace, various GL profilers).
Great post. If only I hadn't blown 30 mod points in the last few days I would have given you +1 Insightful.
Probably they changed from immediate moe rendering to Vertex Buffer Objects, Frame Buffer Objects, Pixel Buffer Objects and the like. By using more modern (as in the last decade years) OpenGL constructs you can get awesome performance, since the GPU and video RAM are doing nearly all the work (rather than transferring across from main RAM and have the GPU stall while waiting for the CPU).
Hardware OpenGL has always been faster than DirectX (there were a lot of companies and talented engineers pooling ideas for OpenGL, plus it has been around a while and worked out a lo of kinks). This shouldn't be a surprise. There was a hiatus where DirectX was ahead on features (we'll ignore the OpenGL extensions, and consider Core only). Now OpenGL has feature parity wih DirectX and works on a lot more platforms (which you could take as OpenGL actually having more features) - including OpenGL's superior support for Windows XP.
Actually the F-22s do this to get good at the close-in fight as well as the long-range engagements the USAF prefers (their tactics are based on a long range 'skate' where they launch and extend - using the superior training and situational awareness [via datalinks and AWACS] to beat their opponents).
What is unusual is the 1 vs 1 nature of the engagements. Usually F-22s and F-15s train at 2 or 3 to 1 odds. Occasionally the USAF loses the fights and the opponents always crow about it (eg. the EF/A-18G that beat a Raptor once, the Indians that managed to win a couple of matches against F-15s at Nellis), what is ignored (since it doesn't make sensational news) is all the times the USAF wins. Now it is totally unrealistic for the USAF to win every engagement without losses (no matter what the aircraft) but the general public seems to have the wrong impression and expect the USAF to have a no-loss record (clearly ridiculous). Now the Pentagon has a vastly more realistic expectation and don't expect the 187 Raptors that were built to be nearly enough - which is why the leaked a report in 2008 to try and get more Raptors built:
Now that is 6 Raptors flown from Alaska to Guam and fighting near Taiwan (not mentioned in the linked article, but that was the scenario) vs around one quarter of the Chinese fighter force. While it was marketed as a "loss" (remember, the Pentagon wanted to scare the US public into sensibility and get more Raptors just in case stealth wasn't the advantage they thought).
Regarding the effacy of stealth. Even the pilots of the F-117A flying over Baghdad thought it might not work. It turned out it did. The pilots certainly realised the limitations of stealth
http://www.defensemedianetwork.com/stories/gulf-war-20th-black-jet-over-baghdad/
Note that the F-117 lost over Serbia was due to the smarts of the Serbians using a combination of visual (and aural) spotters, guessing attack routes, and using very old radars working at wavebands that the stealth fighter is less optimized against. Stealth is not magic, apparently it merely reduces detection range to around 20% of normal for an aircraft of similar size (for the F-117), or 10% for the F-35 and F-22s (from the front aspect).
Stealth is not a silver bullet. It is still an edge (among other several other edges the USAF has) in modern combat.
>you are talking flight sims which has ALWAYS been a small niche to begin with.
I hope you read the article I sent you to see the actual numbers. half a million sales is a decent number (times $7 per sale in the case of the X-Plane author, or $50 in my case), now work out how much money could be made. Even if I got a couple of thousand sales then I would be very happy, and I know that there is easily that number since I created a pilot statistics system for LockOn: Modern Air Combat and used to see thousands of players each month, with about half of those as new players every month.
> Hell its one of those things if you don't have the right controller they suck and how many people have a flight stick anymore?
Again, you are trying to translate the media's portrayal of the console market into the flight sim market. Almost all of the players I encountered in my stats system had at least a mouse and keyboard (which you can use on my sim) and plenty had a decent joystick and TrackIR, and some had nice rigs like mine (Thrustmaster Warthog HOTAS, TrackIR, multiple Thrustmaster F-16 MFDs, rudder pedals, multiple screens etc). Fortunately I had to do little work to support these on my three platforms (Mac, Linux and Windows). JInput, FreeTrack and linux-tracker handle all devices I have encountered so far.
> BTW you ever thought about a space sim? If you want a flight genre that isn't crowded and which has a pretty damned dedicated community THAT would be the one right there. :)) fairly well covered.
Thanks for the suggestion. Yes, I considered this for a long time. I would really love to do a modern version of X-Wing vs Tie Fighter, but up the realism level a little. I couldn't be bothered dealing with the licensing folks at Lucasarts (plus, they have MMOG that cover some of this). It actually turns out that the sci-fi gaming space is already catered for better than modern jet combat. Have you ever looked at Freespace, Vega Strike, StarWraith, Evocron Mercenary, Oolite, Orbiter, Space Engine, Infinity Universe (real nice)? Plus all the existing commercial ones (from Lucasarts etc)? So I consider this space (pun intended
> The guys in those hardcore flight sims can be so anal retentive they'll bitch if you get the fuel switch in the wrong place on that Huey LOL!
Yeah, there certainly are some crazy wankers out there, amongst all the interesting people. Fortunately I have two things on my side: I've done a lot of homework and have NATOPs flight and weapon manuals for the flyable aircraft I'm working on (plus some gems like the NASA flight and fly-by-wire models for the F-16), and also I don't really care about coverage of the fringes of the community in the sense that I'm writing the sim to meet my needs and hope others will like it (which I'm sure they will). I don't feel the need to compromise the sim in order to 'widen the net' to put food on my table (not tossing, but to give you a perspective Java consulting pays me quite a bit more than most of our Members of Parliament - so even modest sales are just icing on the cake for me).
> Oh and if you are having choppers...ever think about maybe adding the Loach? Everyone seems to put the big slow fat choppers like the HU-1 and the Hind but nobody ever seems to go for the light and nimble attack choppers like the Loach. I got to see the civilian version of one of those in flight and they can practically make those sucker dance, nimble as hell and would probably be a blast in a flying game. It would also be cool if you have the Huey and the Hind if a couple of friends could man the door guns, be awesome for MP to have one guy fly the chopper while a couple of other mount the door 50cal and go to town. Be a good way to give the slower choppers a chance against faster opponents.
You can do this already in Armed Assault II (with AA 3 to be released fairly soon, aparently), and the loach is a a lot of fun (especially if you have a TrackIR then flying it around nap-of-the-earth is awesome). It is a
It shouldn't do, ever since Java 1.6.0 u10 (when they moved all of Java2D to DirectX/OpenGL hardware accelerated rendering) it has been blazing fast. What can happen is that new people don't understand not to block the Event Dispatch Thread with processing - if you avoid this then Java is very responsive as a GUI (since multi-threaded resource sharing is so much easier in Java than C++). For non-GUI processing Java has always been very fast, one of the reasons that Java is currently king of the Enterprise space (which makes it invisible to most desktop users). Coupled with the fact that JVisualVM comes as part of the standard OpenJDK/Oracle development kit (JVisualVM is a fantastic profiler that you can attach to any running JVM) there is simply no excuse for slow Java code (apart from programmers who don't know what the hell they are doing, but then there is an old saying, "You can write bad FORTRAN in any language").
If you're not a developer and been reading articles that Java is slow then you are either reading articles from a decade ago (when C++ did have an edge) or from someone who either hasn't developed on a new JVM (and is parotting the statements of uniformed people) or is new to Java development (and so makes elementary and easily avoided performance mistakes, like not knowing to profile with JVisualVM when performance is critical to the application).
As I pointed out, my experience in writing the jet combat flight simulator is that Java is more than fast enough for that purpose, has excellent development time (thanks to existing libraries and tools), is cross-platform, and is completely free/Free (which means I can share code with others knowing they can build it without having to steal or pay for expensive licenses [or slightly restrictive ones, I'm looking at you XNA]).
> Dude I wish you luck but that's an awful teeny tiny itsy bitsy niche you are aiming for.
Thanks man but do the math. In fact, you don't even have to do that, simply look at how much money Minecraft made - at that is a pretty out-there game too. You see the economics of an indie game are different than that of a AAA title - I have none of the overheads that EA has, and nearly all of revenue is pure profit. I think that is the mistakes that many folks make, they think that only the big houses can make money. Here are some actual numbers from an interview of the X-Plane author: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/
Now I'm not targetting iPhone/iPad, but my revenue per unit is nearly a factor of 10 higher (which I know I can get away with, since I'm not entering the target community with no idea - I'm actually been modding the only other product in this genre for a while and paying attention to what that community has been asking for - even if most gamers are completely oblivious to this [but those folks are not my target market, and I don't need them to still be very profitable]).
> But in a way you post validates exactly what my point was, as you had to buy artwork that would automatically put you on the RMS "enemy of freedom!" list for using.
I bought artwork to get a faster time to market (although as an part-time indie dev the time to market is not a critical factor, I make a lot of money in my day job [I don't want to be a tosser, but the fact is that the potential money in this project is nearly all bonus and I have no financial pressures at all to rush it to market]). Now, RMS would say the situation is less than ideal, but it is better that the software works on a Free platform than not at all. Incidentally, I'm considering using a fair chunk of the money I make on the project to commissioning assets that I can release as Free Software (eg Creative Commons), since the money is a nice bonus. I believe I could make a modest living doing this (which you argue is not possible), again since I have very low overheads (unlike big players that must make hundreds of thousands of sales or they can't make back their advances and overheads). Personally I think Free Software is more suited to infrastructure projects where more than on stakeholder can contribute than games, but I still think it is possible to succeed even with games (perhaps not with the same margins and overheads that EA gets, even for their stinkers).
It's 'under the radar' at the moment. You can take that as me being full of b/s if you like, but as an indie/homebrew dev I'd prefer to STFU until very close to release (don't want to promise anything I can't deliver within the next half year). If you've seen or played DCS:Ka-50 or DCS:A-10C then just below that is the quality of product I'm aiming for, but multi-platform (and leveraging all those lovely Java technologies I mentioned, which have saved a huge amount of time - plus all the usual Java goodness like JAXB, JVisualVM etc etc that makes even lil' ol' me much more productive per unit time than someone working on C++).
Sorry I can't give you more info amgo, I intend to reveal a lot at the end of the year. Meanwhile, I'm mid-way through implementing Eric Bruneton and Fabrice Neyret's superb research papers in JoGL/GLSL : check the excellent videos for Proland, http://www.youtube.com/watch?v=2AVh1x-Uqjs, and then just imagine modern multiplayer jets running around there, such as these turbosquid models I licensed:
So, I hope my points about Java + JoGL + JOAL + JoCL + JInput are taken seriously, especially by homebrew/indie game devs that otherwise might be trapped by using XNA when very good free tools are available (I can get less than 1 ms rendering time/1000 fps on an Nvidia 9600 GT mobile on my 2009 MacBook Pro using OpenGL VBOs for the F/A-18 Hornet with around 50k polygons and several textures and a shader for the limb-darkened sun - so Java/JoGL is definitely fast enough for modern games).