Valve Finds Open Source Drivers To Be Great
An anonymous reader writes "Intel's Open-Source Technology Center was given source-code access to Valve's Left 4 Dead 2 game in order to help them fix Linux bugs and to better optimize their graphics driver to this forthcoming Linux native game on the Source Engine. Intel has talked about their Valve Linux development experiences and now they managed to get Left 4 Dead 2 running on their open-source graphics driver. Valve also has grown fond of open-source hardware drivers: 'Valve Linux developers have also been happy looking at an open-source graphics driver. Valve Linux developers found it equally thrilling that now when hitting a bottleneck in their game or looking for areas for performance optimizations, they are simply able to look into Intel's open-source Linux graphics driver to understand how an operation is handled by the hardware, tossing some extra debugging statements into the Intel driver to see what's happening, and making other driver tweaks.'"
Of the GPUs available, Intel has by far the best open source driver. They don't even bother supplying a proprietary one. However, intel GPUs suck, and gamers will have either a nVidia card or an AMD card. There are open source drivers for both of these, but they both suck far worse than the Intel driver.
I really hope Valve can talk either AMD or nVidia into doing something about the quality of their open source drivers. But I'm not holding my breath. Chances are they'll just release a Steam box with Intel hardware instaed.
Give me Classic Slashdot or give me death!
Mixing free software and commercial software can sometimes work wonders. Sadly sometimes is a misunderstood thing.
-Woof woof woof!
Since they are kick ass.
Even for performance.
Too bad afaik Intel doesn't do any consumer graphic hardware which is as kick ass as Nvidias and ATIs though.
But yeah, watch Phoronix for Linux Intel OpenGL drivers vs others.
I have this feeling that Linux community (or the larger free software community - ESR fans may simply not care) ever since announcements of Steam and L4D ports got public, thinks of Valve a little too high than the company deserves. At the same time as they criticise Windows 8 walled garden, they are pushing new TOS to their Steam service users which, most importantly, dropped the notion of owning a digital "product" in favor of "subscribtion". This is yet another step on the path towards taking our legally purchased software away from us.
As Linux serves to give it's users total control over their computers, I think at least part of community should rethink their enthusiasm over Valve coming to Linux platform. In my opinion, some of practices it brings are totally at odds with free software values.
PS. captcha "dissent", very true.
Open Source != Linux
In case you are not familiar with basic programming/math syntax, the above means that the two are not the same.
This is good news, because a company like Valve might actually have the clout to get AMD and/or nVidia to release good open-source drivers. After all, if it wasn't for the games released by companies like Valve, a heck of a lot fewer PC owners would need/want discrete video cards. And neither AMD nor nVidia wants a popular game to run worse on their card than on their competitors.
Linux IS a good platform for games. As said, you can see what's happening at every level, which mean no need to workaround weird unexpected behaviors and stuff.
Linux isn't a good platform for some game developpers, because of the small user base. But for Valve, aside from the initial work of porting their Source engine, it only means more reach. Having the engine already work on macs probably helped a lot. And if great games start to be available on Linux (and I mean more than one AAA game per year, at most), it might also leverage the linux presence.
Giving the user the choice is the only sensible choice for people working with their brains, and Valve's pretty good at it.
You'd think this would be obvious... but it's good to see someone stand up and take notice. Of course having the source is extremely beneficial, especially if you have the inclination and skills to interact with it (or can pay someone who does possess these qualities). I hope this gets lots of coverage. Maybe with more eyes and more review, people can spend more of their time creating and trying new things and less time recreating the wheel. Open source is an excellent way to help achieve that goal.
I think you use the word 'supported' loosely.
Seriously, other developers would never try to experiment with linux, due to the cost it would result in. With the massive budget that valves has with Steam, they can afford it and it can only do good for all of us.
Apples and oranges. Carmack was talking about the financial viablity of targeting games to run on desktop Linux. Valve is talking about the two platforms from a developers perspective.
Carmack as said that Valve entering the desktop Linux market changes thinks somewhat.
Work bio at MMWD
Valve is sitting in closed rooms patting itself and Intel on the back.
Intel GPU performance and drivers have in every encounter I have suffered them - blown. Yes, they will do basic workload gfx wise. They will run office. They run basic apps. The times I take complex apps and have problems are legion. Its great that Intel and Valve are debugging the worst hardware in the PC gaming arena. Great. Even the current HD4000 leaves much to be desired.
Might I suggest this is the last place Valve should be knobbing around? If the aim is to make Linux + Intel garbage GPU a gaming platform, I'll even vacate to consoles.
Maybe its a case of 'we must make steam and our games work from the bottom up'. If so, then I'll cut some slack.
Valve need to be focusing and getting on board Nvidia and ATI. They are the only really viable PC gaming platform centric hardware to focus on, and IMHO its the only place to focus.
But I said this at the beginning when Valve started down this road. Its a horrible broken lonely road, with vendors not liking Linux enough, and Linux being in a mess at driver and API level.Valve will need to drag the API and driver layers and APIs together (and form up a direct X alike organised, working, stable layer) because no one else is going to do it for them. As they require DRM, they have a perfect vehicle to offer the GFX vendors a driver layer that is open to closed source/binary layers.
All the positive stuff coming out can be ignored. This will be a huge uphill battle, and they are only at the very edge of this task. Even if they get their Source platform working to a vague level, the rest of steam is far far behind, with most Windows Games being Direct X based for a start.
And even if you make Linux + Steam a gaming platform. Its a very long way off Steam + windows. A very very long way off.
We`re all equal
Maybe developing with open source graphics drivers is great, but that's a different story than the state of graphics on open source.
Graphics on Ubuntu are terrible in my anecdotal experience. On my last laptop, installing Ubuntu 9.04 failed during install and dumped me at a command prompt because it didn't support the correct drivers to display the graphical install. That was the first and last time I attempted to run Ubuntu on that laptop. Or on my newer Envy 14 with dual ATi and Intel graphics. 10.10 installs fine, but then tells me there's an upgraded driver, which if installed will prevent the computer from booting. Wonderful. Then there's the fact that it's running both graphics cards at once because there's no hybrid support, so battery life is shit and I can't output HDMI. I can't run the newest 12.xx releases with Unity, since it says I need graphics acceleration and my machine can't handle it; it's probably looking at my Intel card and concluding it's not good enough, while ignoring my ATi card.
Then there's my quad core HP DV 7 laptop, which I can get HDMI output on. Except you have to configure it manually every single time you connect a monitor. I have to connect the monitor, detect it manually, enable it manually, then rearrange the monitor relationship manually every single time. Repeat if I want to disconnect.
Sorry, I won't be even considering running games on my Linux boxes/laptops. I'm running Windows 8 on my gaming laptop and it handles graphics, HDMI out, dual cards, dual monitors, Steam, all games (not just Source games) just fine. Why would I ever subject myself to the mess that is graphics on Linux?
>Funny how Valve just *loves* Linux now that Microsoft threatens their primary business model. Meanwhile, John Carmack, who supported Linux before it was trendy and cool and has no financial incentive to shit all over Microsoft claims that Linux is not a good platform for games. Gee, I wonder who I should believe?!?!
John Carmack did not say that linux is not a good platform for games. He said that the games that ID-Software ported on linux did not earn the cost for porting. This is a hard fact.
But, no wonder that this is the case. Most gamers that use linux although have a windows partition for gaming. And when the windows version of a game comes month before the linux version, you already "lost" a big part of the potential linux market to the windows version.
Now, Valve shit their pants because of the windows market, and try to change it. And they have the power. Valve can solve all the distro and patch problems for the developers. If they deliver an easy way for game developers to reach the linux audience, linuxgaming will hopefully be a worthwhile market.
The obligatory xkcd.... http://xkcd.com/619/
But it's not a joke. Intel Sandybridge still doesn't have stable tear free video. They finally came out with an option of getting rid of it the lastest driver, but it enabling it makes Xorg too unstable. Sandybridge has been on the market for a long time and is now becoming obsolete and intel still can't get it work properly. This is not what I would consider excellent driver support.
No matter how you twist it, if Linux gets graphics drivers on par with Windows, it is much better for games since it wastes much less resources.
Case in point: My Linux installation at work, which is an 8 core, 16 GB RAM computational workstation, uses 231 MB of RAM after I've logged in. Two days after last reboot, with five terminal windows, Firefox with a dozen tabs, Citrix (to run Outlook, restrictive company Exchange policy...), Gimp, Blender, two additional CAD programs, and two instances of a PDF viewer, I'm still only using 1.7 GB RAM.
On the same system, Windows 7 uses 1.5 GB after I've logged in, no programs running. And yes, I'm using both preload and readahead on the Linux system, so don't give me the "Windows uses RAM to store things it will need in the future" because my Linux does as well.
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
But do their insurance rates reflect this?
Valve also thinks denying (coercing) clients their fundamental right to pursue cooperative collective class-action lawsuits against the company, even when such suits would be ethically warranted, is great. In that context, as a Valve client who wishes he could get his damned money back for the games he can now no longer access or play, even in single-player modes, for having resisted the aforementioned coercion, I couldn't care less what Valve or Gabe Newell thinks about open source drivers or anything else.
>And yes, I'm using both preload and readahead on the Linux system, so don't give me the "Windows uses RAM to store things it will need in the future" because my Linux does as well. If you're *only* using 231MB of 16 gigabytes, you're not caching nearly as many things as it could/should be. The only point you make is that Linux is terrible at putting your system's resources to good use.
Similes are like metaphors
is shaking in its collective shoes right about know, isnt gaming kinda one of the biggest things keeping a ton of people on windows?
The reign of the old shogunate, is over.
As always, all IMO. Insert "I think" everywhere grammatically possible.
No, Linux is not a good platform for games. All of these tweaks that valve is making to the drivers are an indicator that the drivers are immature and don't provide the same level of performance as they do in Windows.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Two days after last reboot, with... Firefox with a dozen tabs... I'm still only using 1.7 GB RAM.
You'll have to excuse me while I call bullshit on that. Firefox with a dozen tabs will take up 1GB easy, and I find it hard to believe that your CAD programs and Blender aren't sucking down at least another 700MB without even considering the other running programs, the OS kernel, and the XWindows system.
I assume he means that the Linux system uses 231MB for process allocation. This isn't counting filesystem cache.
Windows seems to have the same concept, sort of. I think. At least, it seems to list "cached" memory as total - used, and I assume that means fs cache. I have no idea if the prefetch stuff resides in cached or used memory though. What I do know is that if used gets up to total, it starts swapping like crazy, so I sure how they would drop the prefetch cache before it swaps...
On UNIX machines, some filesystems actually use the free memory as a cache, but leave it marked as free in case an application needs them.
UFS for instance does this, while ZFS for instance does not (it uses an explicit cache).
so don't give me the "Windows uses RAM to store things it will need in the future" because my Linux does as well.
Apples to oranges. The two systems use different memory management schemes. Case in point: 8 GB laptop, with some explorer addons and several background services (including Forefront antivirus), and I use ~900MB of RAM. I understand that under memory pressure, Win7 can work quite well with as little as 512MB, which is about the minimum I have seen your average modern Linux desktop work well with.
Of course, if you want to compare a stock Win7 desktop with something like XFCE with no addons or icons or anything, you can do so, but its even more apples to oranges. What sound manager are you using? Is compositing on, or off? Do you have any indexing enabled? Are any background services running in the Windows box, or is it a fresh install? How did you measure the RAM usage? All of those uncertainties make the comparison you gave worthless.
And at the end of the day, it really doesnt matter what "free RAM numbers" are reported-- it is irrelevant if Windows 7 fills every spare bit of RAM with images of unicorns and always reports "100% RAM usage", so long as it releases that memory when needed. A more meaningful comparison would be to see what happens under memory pressure: Which box can open more tabs in Firefox without paging? THAT is a relevant question, since its the only one that has any meaningful impact on the computer's performance.
For the record, the recent Linux distros Ive tried (maybe a year or two ago?) performed rather poorly under 256MB RAM. I havent tried Win7 on anything less than 1GB, so cant comment on that.
So to be competitive, hardware manufacturers may have to provide their driver source? Perhaps at least to the developers. But that could be anyone really, and the next Minecraft may run better on Intel graphics hardware than any other because some amateur developer was able to wring performance out of it that much more easily.
But at the level that AMD/ATI and nVidia are competing with each other, perhaps the one to take the edge will be the one that provides open source drivers.
Twinstiq, game news
system ram is slower then video ram and with cards having 1-2GB of ram now days that is a BIG CHUCK on system ram to use and shearing it makes so you really can't say block off 1gb of ram just for video use.
You gotta be trolling. I'm running dual-boot too, and just about everything I do goes so much smoother in Linux than in Windows. From my usability point of view, it feels like windows is just squandering resources. GP's numbers do seem about right to me.
That said, I've always felt uneasy about "comparing the numbers" between Linux and Windows. The way windows' Task Manager reports memory usage is different form the default "top" view, and they're both somewhat nontransparent to the uninitiated because virtual memory management is complicated business. To make an apples-to-apples comparison, one has to precisely analyze how much memory is cached, buffered, swapped, committed and allocated. To make matters more difficult, Linux distros and users have a strong inclination to customize how the kernel manages memory and what software is being loaded, so there will be huge differences between different Linux measurements. And even windows can be leaned out or fattened up to a great extent by users and OEMs.
Maybe you should believe the company making money hand over fist, as opposed to the programmer who hasn't made a decent game in years.
You're misunderstanding Valve's position. They're not tweaking the drivers so much as using the source to understand which operations in THEIR software behave poorly. You're also ignorant to how much tweaking is already done in video games to make them work under Windows. Look at the furor Rage's release last year caused because AMD's drivers were broken and id Software didn't jump through hoops to make it work on that platform like so many other companies do.
Valve, and the numbers, disagree with you.
http://www.bit-tech.net/news/gaming/2012/08/02/valve-linux-performance/1
There is one huge point that your all missing and is likely why Valve even mentioned it in the first place.
More often than not the techniques that work great on one graphics chipset, works just as well compared to alternative techniques on other graphics chipsets. Being able to modify the driver to measure the differences or track down obscure bugs, is a massive boon. It makes tools like Intel GPA and Nvidia's PerfKit look like childs play.
> Carmack was talking about the financial viablity of targeting games to run on desktop Linux.
Remember, there is an enormous difference in targetting games to write on Linux *as well as other platforms*, compared to targetting games for Linux only (which would be a financial mistake). I'm currently using Java+JoGL(OpenGL+GLSL)+JOAL(OpenAL)+JInput to write a combat flight simulator. I develop on Mac and test on Linux and Windows. Because I have chosen these technologies the only cross-platform issues I have are slight peculiarties in the OpenGL driver implementations (AMD vs NVidia) on each platform - and these are pretty minor.
It would be expensive to include a Linux port if I was working in C++, and Carmack would be right about that. But since I'm using Java (which is very, very fast for my purposes - the bottleneck is GPU performance by far since all the large effort is done in shaders) having my program work on Java pretty much comes for free (and I used to do a lot of cross-platform C and C++ in the day, so I don't make the stupid platform-dependent mistakes that many other devs do ; eg. put in platform-dependent filepath separators rather than use File.separator, etc). Hence, I must disagree with Carmack's statement. A Linux port is not financially viable for him since he is using old outdated technology to build his software (that is, C++, which I have used for two decades, but am glad that OpenJDK/Oracle Java is now super fast and I don't have the PITA of C++ anymore; plus multi-core apps with *shared resources* are vastly easier to build [which means Java's multi-core performance destroys C++ single-core any day]).
So, while Carmack may be a genius when it comes to graphics algorithms using the technologies he has used for a long time, it turns out that in terms of "financial viability" Linux is perfectly possible provided you are willing to adapt to more modern tools.
Final note: the world is becoming increasingly more cross-platform, not less. So if you are using technologies that require effort to port between platforms you may be making a good technological choice but a poor 'business/financial' choice. Hence, I prefer Java to C/C++/C#(Mono doesn't count; the libraries are not the same as C# ones) etc for most of my work since 'porting' is so easy.
Valve is also hugely relevant to modern game development.
John Carmack... not so much. His engines aren't state of the art and the games id produces aren't very good.
John Carmack is like the game development equivalent of Eddie Van Halen. At one point in time he was an absolute master, but not anymore.
Mod me down, my New Earth Global Warmingist friends!
C++, outdated? What are you smoking, son? Ah, I see you've drank the Java kool-aid. Moving on.
so instead of needing a driver (to abstract from) for the grafic hardware, you now need a driver for ... EACH GAME.
While we're at John Carmack, he also said that he found the Intel open source drivers really interesting to look at, and recommended it to anyone else writing a graphics engine. He then proceeded to say that if he could clone himself so he would have more time, he would love to work on optimizing them.
So it's not just the Valve developers who see the benefit of open source drivers.
Ok, let me pose a simple question for you. Let's say you have some big objects in your program and you want to put them on the heap. Now, to get good performance out of your program you are going to make it thoroughly multi-threaded. Now, because the market is getting more and more diverse you want your program to run on Mac, Linux, Windows and Android. You don't have the resources of a global mega-corp to achieve this but still want to get the project done. Should I use C++ with its problems between compiler versions (ah, the joy of porting your C++ program between 0.1 releases of G++) let alone compilers, plus the effort of porting between operating systems, plus choosing which library to use (for multi-threading and synchronization [standardized in Java], GUI [standardized in Java], network I/O [standardized in Java], device input [cross-platform with JInput], audio [cross-platform with JOAL]). etc etc.
Have you ever built (or tried to build) such a cross-platform, high-performance, networked (multiplayer in my case), multi-input device program yourself? If you even attempted this (probably not, yeah?) was it a nice experience in C++?
Let me assume you have never actually done this yourself, that means you dare to accuse others of having drunk the "kool-aid" when perhaps they are the ones who have done such development 'in anger' and are trying to enlighten others into using far more modern tools and techniques. That's why when I hear such anti-Java nonsense from C++/C#/Python folks who have never even tried to proper *very large, portable and complex* apps I get cranky, since these folks simply have no idea about the reality of developing such applications in 2012 (where Java is, IMHO, the best tool to solve the problem when you consider business/financial/time-to-market factors in addition to technical ones).
C++, its tools and common techniques are fairly outdated. That doesn't make C++ useless (I still use it whenever I have to integrate hardware), but it hardly makes it the first or best choice for modern applications. Once you are able to write clean (Javabeans without cruft ftw!) and legible Java code that is performant (eg. when to use different parts of the Java library eg. String/StrungBuffer/StringBuilder; and including learning how to use JVisualVM included in the JDK) then you would never go back to C++ (like I said, I have two decades using C++ and I'm always dislike going back to it on the occasions I have to - everything about it and its tools are outdated).
So, I'd be interested to hear back from you if you have actually written a large, complex, multi-threaded and multi-platform program recently and found C++ the best tool for this purpose and why. Otherwise, admit to yourself that perhaps it is your perspective (as well as C++ itself) that is actually outdated.
Let's also point out that you could buy the cheaper Windows version, download a binary, and use the Windows version to game on Linux. And people wonder why the Linux sales were not good?
You're right, I have never written a huge application in C++. I have, however, used both of them, and Java has always been a pain to work with.
I find Java to be a bad language because:
You said you were developing a flight simulator. I'm programming a game myself as well in C++ using SDL, which already makes it more cross-platform than if I had programmed it in Java. It can be run all the way back on Windows 95 to Windows 7, many Mac OS versions, Linux, and even on more obscure operating systems like BeOS and its open source effort Haiku.
C++ is standardised, which is what makes all of this possible. As for your specific complaints, they're getting addressed in C++11. I will admit that it's a bit late, but it's getting there nonetheless.
> You're right, I have never written a huge application in C++
Ok, when you scale an application you get different concerns. The complexity does not increase linearly with size and with C++ it simply gets very very hard to write a large, correct, and reliable program - especially when multi-threading heavily and going cross-platform.
> it uses more memory than C++ with its garbage collection paradigm. Java enthusiasts always excuse this saying that you should get more memory or that newer computers will have more.
Java uses more memory for tiny programs due to the overhead of the virtual machine. Once the program is large (that is, a non-trivial application) then this overhead is negligible. Now C++ can allow you to do all sorts of neat but dodgy optimizations if you want but that is not conducive to reliable programs. Actually, with computers these days shipping with between 4 and 8 of RAM these days memory constraints are fairly rare unless you are programming in a very niiave way (eg. holding on to large buffers/images far longer than you need them). The real memory constraint for me is video RAM, and C++ overs no advantage over Java in this regard (and, due to the long development time, C++ is at a considerable disadvantage).
> it's slower than C++. In order for a Java program to run first the JVM has to be started and compile the bytecode. Granted, once it has run for a little, the JVM has found ways to optimise the bytecode into something that runs at more or less the same speed at C++, but there's still that initial penalty. Of course, the excuse every time someone mentions this is that recent updates to the JVM have added performance improvements. Yeah, we've seen those. They don't make much of a difference. it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
Again, this only matters if you are running tiny programs and the year is 2005. Ever since then the JVM is usually pre-loaded (just like other system libraries) or loaded on first use (depending on OS) and the start-up time is negligible. Now, as you admit, for large programs this is a non-issue, and for my large sim once the JIT compiler gets into it the speed-ups are fairly impressive (and I don't have to micro-optimize since the vastly more clever Sun engineers do it for me).
> it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
You would prefer a stagnant platform that is outdated, or updated each decade (like C++) ? nb: GCJ (based on GCC/G++) may be a suitable Java implementation for you then, but OpenJDK performs considerably faster.
> it has bad backwards compatibility. Parts of the language get deprecated over time. Java applets made during the 90s often don't work any more.
Java's backward compatibility is vastly better than C++'s. Why? because C++ has so little functionality in its standard library it depends on external libraries to get much useful stuff done. These have mostly changed since the 90s which means that non-trivial C++ programs have to be recompiled every couple of years to work on new platforms. With Java the library is very stable (although there are some avoidable exceptions, eg. DataSource.getParentLogger() change between JDK 6 & 7), all of my very old Java programs still run without recompilation - mostly since I was used to writing cross-platform apps in C++ when I wrote them in Java so I avoided all the pitfalls that later generations of developers fall in to (those that have only ever known a Windows desktop, and believe the IT world will be like that forever).
> it's unintuitive. Want to compare strings? Use the equal method instead of the equal signs. Want to manipulate strings? Wait, use the StringBuilder! I'm aware that this is like this to keep Java 'clean', but I think operator overloading and easy string manipulation makes things easier. Besides, Java stopped being
Funny thing they claim better performance on Linux than on Windows, trollboy.
ranma - girl?
That's exactly the excuse I was talking about. You have no business using loads of RAM for your application. You should use as little as possible to run on as many computers as possible and allow as many other programs to run as possible (instead of just today's). You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
I neglected to mention how the garbage collector will only clean up when it feels like it and slow down your program. This makes it unsuitable for time-critical programs like video games.
The same excuse was used in 2005 with a different previous year. And if Java is so great it should be good for tiny programs, too.
Just like C++ compilers do the micro-optimisation for me.
Stability is preferable.
You didn't address the Java applets that broke.
In other words, Java moved the compatibility problem into the JVM, which I don't think was a good idea.
The older C++ libraries are always shipped with the program so everything just works without a problem. No recompilation needed.
I started with QBasic, then went to Visual Basic, C, VB.NET, Java, C++, C#, and JavaScript. Once I learned the basics, they were easy to work with, except for Java which has consistently been a pain.
Strings are such a fundamental data type that they should work like one. Other languages have understood this.
I'll keep that in mind when I start gaming on integrated graphics. Meanwhile, my Radeon card will continue running under Windows.
> That's exactly the excuse I was talking about. You have no business using loads of RAM for your application. You should use as little as possible to run on as many computers as possible and allow as many other programs to run as possible (instead of just today's). You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. Memory is there to be used. In the case of a game it would be negligent not to efficiently use all the resources that were available. In the case of a general application the application should play nicely with others. In my experience even small Java applications do not have a memory footprint that is excessively larger than other complex applications. For system tools you could argue differently but in fact I have created lots of little Java applications for myself in the nature of Unix tools and memory use has never been an issue. Your view is outdated (just like C++ application development).
> You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. You don't know the market I'm aiming for at all. In fact, combat flight simmers are not running their sims on their iPhones or tablets. Even consoles are too weak for proper simulation. These simmers often upgrade their machines (or the major parts) every two years. So you see, I'm not aiming for the lowest-common-denominator market as your incorrectly suppose, it is completely uneconomic (not to mention uninteresting) to support low end machines (eg. puny integrated graphics). Once nice thing I will say is that my program runs very very smoothly (so easy to massively multi-thread in Java while sharing resources) and much more reliably on the same hardware than the DCS:Word simulator (you're probably totally unaware about this simulator, which is the current market leader). Unfortunately DCS:World is still in beta stage, but has quite a few bugs (it's written in C++) that cause crash-to-desktop that I simply don't have to worry about in Java (one of the reasons Java was invented). Given DCS:World's predecessors (and C++ games and development practices in general) I think that this will never be fully resolved (again, another reason motivating me to choose Java over C++).
> I neglected to mention how the garbage collector will only clean up when it feels like it and slow down your program. This makes it unsuitable for time-critical programs like video games.
Wrong. There are lots of garbage collectors to choose from. You can get deterministic garbage collection with real time Java. However, I've found the G1 and parallel collectors to be sufficient for my needs (using less than 1% of CPU every 5 seconds or so - as shown by JVisualVM which comes with the JDK; it's like g++'s gprof but much much better). So, here I am, a game developer and you are telling me that the current Java garbage collectors are unsuitable for games? looks like you don't know what you are talking about (I'm starting to get a theme here) since you appear to be basing your statements on outdated information.
Also, people used to blame Java or the garbage collector when there were pauses in Java GUI programs. This occurred when bad developers blocked the Event Dispatch Thread (something competent Java developers are trained/know not to do). This is wrong and borne of ignorance. There is no fundamental problem with latency in Java (well, not worse than the other latencies in your system, like the millisecond-increases in latency in the O/S scheduler when I/O is happening etc).
> The same excuse was used in 2005 with a different previous year. And if Java is so great it should be good for tiny programs, too.
Wrong. I have created small commercial Java programs to run embedded systems on single board computers. Initially I used gcj but it turns out the Sun JDK was fine for this use. The result was tiny (even if using very complex logic). You can do ti
As far as I know you're not a recognised authority on programming languages and just another Slashdot user. I don't have to believe anything you say. From my point of view you're just drunk on Java kool-aid on your high horse and living in your own world.
Hell, I can just claim that you don't 'get it' either and that I have far more experience than you think. But this isn't getting us anywhere, so I think I'll move on.
> I don't have to believe anything you say.
No you don't. But what you could do are check facts instead. Either build a modern program (eg. game) in Java yourself (doesn't have to be big, just a little one - and profile with JVisualVM) or look around on the web for *current* statements that prove or disprove my assertions. I don't expect you to believe my statements based soley on my assertions - I'm confident that if you actually took the time to check you would come to the same conclusions I have: the areas where Java used to be weak and C++ was strong have pretty much disappeared, therefore new development in C++ is unnecessary for the vast majority of developers, therefore C++ is outdated (compared to more modern tools and techniques; this was my original assertion).