Game assets rarely work "stand alone". They often are not reusable and designed for a very specific game. Use them in something else, and the result looks odd. It gets worse when you mix stuff from different games. So, something like a game asset archive would only be useful for placeholders and basic material the artists may choose to work on.
There are pre-made mesh and texture packs from graphics artists, often they cost around $30-100. Again, you do not make up the game solely based on these pre-made meshes. (Textures are very often bought, though - note how many games have similar textures..)
For the finished material, you have to create new content. There is no other option.
Well, HL2 does work very well with renderings that resemble the real world. Of course UT3 could not work with it, but comparing HL2 and UT3 is absolutely pointless. I like both games, but I would never even think of re-doing HL2 with the Unreal Engine 3.
I mentioned MS because of its 800lbs gorilla status. This gives C# a competitive edge over other languages with much less influential and powerful backers.
There are several other languages which are more powerful and interesting than Java or C#, but technology can get you only so far; at some point, marketing has to take over.
First, we don't have glorified calculators on our desktops. Calculators usually aren't turing complete, PCs are. As for the neural networks, while there are many problems that need to be overcome, digital technology isn't one of them.
Moc is a comparably small price to pay for the excellent and powerful API. Typically, the connect() lines sum to up to 1% of the code. Once the build system is set up properly, moc is no longer a concern either.
Also consider that Moc signals/slots allow for introspection and adjustable behavior (direct emitting, delayed emitting etc.), which is especially useful for thread-safety and cases where the emitting widget ultimately ends up deleting itself.
Note however that many areas where basic research is done nowadays have become far more complex. The era of single scientists (or small teams at most) making major discoveries is past. Research now requires teams and considerably large investments. Michelson and Morley could construct the apparatus for testing the presumed effect of the Aether on light. But Michelson and Morley could never ever have built something like a LHC.
This fight has always been happening. Just imagine how hard it was for intellectuals in the Middle Ages to even get a book, let alone exchange information.
I don't think we are *devolving*. Instead, I think three things are happening:
Thanks to telecommunication, we get a LOT more information. In the past, you didn't really notice the masses of ignorant people, now you do. (This also applies to things like "so many more catastrophes/crimes/etc. nowadays" - they have always been around, we just did not know about them)
The amount of ignorant people increases faster than the amount of people interested in science - but the ratio between the two is constant. Today, you have zillions of reality shows, nonsensical talkshows and "news", religious nutcases and politicians spewing their garbage in the networks etc. But on the other hand we have *many* more universities, scientists, labs, research facilities, libraries, advancements than in the past.
Today's research focuses - has to focus - on incremental improvements. Huge, mindblowing breakthroughs are becoming increasingly rare. However, this does not mean research as a whole is stagnating, its just our perception that cannot really grasp the overall impact of all these myriads of small improvements.
Don't get me wrong, fighting shallow mindedness is TOTALLY necessary, but it has always been. There has been no "golden age" where everybody was open-minded and well-educated.
So, shall we nominate you the head of the new Citizen Morality Correction Center? Or do you prefer leading the Citizen Behavior Optimization Section instead? Hey, how about constantly monitoring everybody's mood, so nobody dares to be unhappy! Yes, that sounds great!
I cannot reconstruct any of these points (minus the centre resize thing and the rotate, though I do not consider the latter to be a problem). What distro are you running? Note that Kubuntu is among the WORST KDE based distros, riddled with bugs, slow etc. I am using debian squeeze with KDE 4.2.
The "OS" is little more than the main menu you get at the start. Today's consoles remind me a lot of the Commodore Amiga; there is an OS, but the programs have the option to completely bypass them, and return control to the OS cleanly. If you want to squeeze out performance, this is what you have to anyway. I would not be surprised if games effectively shut down the OS (or at least large parts of it) and restart it when necessary.
As for DirectX: exclusive AAA titles still use the 3D hardware directly. Why shouldn't they? There is no point in using this extra layer on a hardware that never changes. The same applies to OpenGL on the PS3.
Wrong. Your platform is NOT decided at the API layer. Your platform is Windows XP, Windows Vista, Windows 7, OSX Tiger, PS3, Wii,...
First, consoles have no API. You use the hardware directly. Second, you forget that writing platform-neutral code that is not a lowest common denominator and used the maximum power of each platform instead is HARD and time-consuming to do (and mostly happens in game engines that are then sold as middleware). Third, you forget QA and support.
In the real world, specific platforms are targeted from the start: PC (meaning: Windows XP/Vista), Wii, PS3, etc. Additional platforms may be targeted later, as a port. What you never do is simply rely on some system API. This is a maintenance, QA, and support nightmare. Add to that the typically very tight time constraints for development, and hacking for a few specific platforms becomes a necessary option. Again, you cannot rely on some system API here, because the hacks often involve very platform specific behavior.
I have personally worked on QT embedded projects as well, for well over a year. Some platforms weren't supported out of the box, yet I didn't find it to be particularly painful. Neither was the signal/slot-system. I did use GTKmm before Qt though, and had to endure all the braindead API designs inherited from gtk.
gtkmm is sort of ok, but Qt is still superior. It has a much cleaner API, better documentation, a MUCH more powerful canvas widget, support for reflection of QObjects (very useful for stuff like RPC), etc. gtkmm on its own is fine, but it suffers from having to inherit the gtk wall bangers, most prominently, the API.
How about this: learn to distinguish between the actual language, and the browser API? JavaScript is standardized, and a fine, Lisp-like language. Browser APIs (DOM among others) are not.
As the GP said, violence and wars were far more frequent. Violence was a regular part of daily routine. You cannot really talk about post traumatic stress disorder there - those who couldn't handle it didn't make it far.
Unfortunately, Sarkozy is in love with the music industry, which in turn is one of the biggest enemies of free speech, freedom of expression, democracy, and privacy.
Anything else other than hardware h.264 decoding is not going to work. Big performance bottlenecks include debinarization and motion compensation. SIMD won't help you much there; a dedicated h264 chip will.
Game assets rarely work "stand alone". They often are not reusable and designed for a very specific game. Use them in something else, and the result looks odd. It gets worse when you mix stuff from different games. So, something like a game asset archive would only be useful for placeholders and basic material the artists may choose to work on.
There are pre-made mesh and texture packs from graphics artists, often they cost around $30-100. Again, you do not make up the game solely based on these pre-made meshes. (Textures are very often bought, though - note how many games have similar textures..)
For the finished material, you have to create new content. There is no other option.
Well, HL2 does work very well with renderings that resemble the real world. Of course UT3 could not work with it, but comparing HL2 and UT3 is absolutely pointless. I like both games, but I would never even think of re-doing HL2 with the Unreal Engine 3.
I mentioned MS because of its 800lbs gorilla status. This gives C# a competitive edge over other languages with much less influential and powerful backers.
There are several other languages which are more powerful and interesting than Java or C#, but technology can get you only so far; at some point, marketing has to take over.
You are new here, aren't you?
First, we don't have glorified calculators on our desktops. Calculators usually aren't turing complete, PCs are. As for the neural networks, while there are many problems that need to be overcome, digital technology isn't one of them.
I put my money on C#/Mono, since it is technically the better platform with MS behind it.
Moc is a comparably small price to pay for the excellent and powerful API. Typically, the connect() lines sum to up to 1% of the code. Once the build system is set up properly, moc is no longer a concern either. Also consider that Moc signals/slots allow for introspection and adjustable behavior (direct emitting, delayed emitting etc.), which is especially useful for thread-safety and cases where the emitting widget ultimately ends up deleting itself.
Note however that many areas where basic research is done nowadays have become far more complex. The era of single scientists (or small teams at most) making major discoveries is past. Research now requires teams and considerably large investments. Michelson and Morley could construct the apparatus for testing the presumed effect of the Aether on light. But Michelson and Morley could never ever have built something like a LHC.
Don't get me wrong, fighting shallow mindedness is TOTALLY necessary, but it has always been. There has been no "golden age" where everybody was open-minded and well-educated.
So, shall we nominate you the head of the new Citizen Morality Correction Center? Or do you prefer leading the Citizen Behavior Optimization Section instead? Hey, how about constantly monitoring everybody's mood, so nobody dares to be unhappy! Yes, that sounds great!
I cannot reconstruct any of these points (minus the centre resize thing and the rotate, though I do not consider the latter to be a problem). What distro are you running? Note that Kubuntu is among the WORST KDE based distros, riddled with bugs, slow etc. I am using debian squeeze with KDE 4.2.
The "OS" is little more than the main menu you get at the start. Today's consoles remind me a lot of the Commodore Amiga; there is an OS, but the programs have the option to completely bypass them, and return control to the OS cleanly. If you want to squeeze out performance, this is what you have to anyway. I would not be surprised if games effectively shut down the OS (or at least large parts of it) and restart it when necessary.
As for DirectX: exclusive AAA titles still use the 3D hardware directly. Why shouldn't they? There is no point in using this extra layer on a hardware that never changes. The same applies to OpenGL on the PS3.
Obviously, DOM != language. The DOM is more like a standard library.
Otherwise, I don't see much of a reason for having an open source Quake Live clone especially when the service it seeks to clone is free as well.
The real reason for this is for the FSF to finally get a chance to call something "GNU Quake".
Wrong. Your platform is NOT decided at the API layer. Your platform is Windows XP, Windows Vista, Windows 7, OSX Tiger, PS3, Wii, ...
First, consoles have no API. You use the hardware directly. Second, you forget that writing platform-neutral code that is not a lowest common denominator and used the maximum power of each platform instead is HARD and time-consuming to do (and mostly happens in game engines that are then sold as middleware). Third, you forget QA and support.
In the real world, specific platforms are targeted from the start: PC (meaning: Windows XP/Vista), Wii, PS3, etc. Additional platforms may be targeted later, as a port. What you never do is simply rely on some system API. This is a maintenance, QA, and support nightmare. Add to that the typically very tight time constraints for development, and hacking for a few specific platforms becomes a necessary option. Again, you cannot rely on some system API here, because the hacks often involve very platform specific behavior.
I have personally worked on QT embedded projects as well, for well over a year. Some platforms weren't supported out of the box, yet I didn't find it to be particularly painful. Neither was the signal/slot-system. I did use GTKmm before Qt though, and had to endure all the braindead API designs inherited from gtk.
I am using KDE 4.2 right now, and it is amazing. Everything works well, no bugs, no problems. The underlying tech is easily superior to gnome as well.
Honestly, how many KDE4 bashers have actually *tried* it?
gtkmm is sort of ok, but Qt is still superior. It has a much cleaner API, better documentation, a MUCH more powerful canvas widget, support for reflection of QObjects (very useful for stuff like RPC), etc.
gtkmm on its own is fine, but it suffers from having to inherit the gtk wall bangers, most prominently, the API.
How about this:
learn to distinguish between the actual language, and the browser API?
JavaScript is standardized, and a fine, Lisp-like language. Browser APIs (DOM among others) are not.
As the GP said, violence and wars were far more frequent. Violence was a regular part of daily routine. You cannot really talk about post traumatic stress disorder there - those who couldn't handle it didn't make it far.
Mod parent up. This is by far one of the most important things to consider in such discussions.
Unfortunately, Sarkozy is in love with the music industry, which in turn is one of the biggest enemies of free speech, freedom of expression, democracy, and privacy.
I can set up 40GB+ of music to play via a decent-looking web interface for anyone I send a password and URL to
Nobody expects the RIAA inquisition!
Actually, a considerable amount of commercial games use Vorbis as well: http://wiki.xiph.org/index.php/Games_that_use_Vorbis
Anything else other than hardware h.264 decoding is not going to work. Big performance bottlenecks include debinarization and motion compensation. SIMD won't help you much there; a dedicated h264 chip will.