No, game AIs will be designed by humans for a long time to come. The good ones are usually tuned very well to provide a very specific experience to the player. A big part of game design is to define this experience and behaviour. Automatic tuning risks altering the game in ways that deviate from the designer's intent too much and might make the game unplayable. The game may become too hard or too easy or the learning algorithm may decide to optimize the AI to exploit some obscure game rules or even a bug to become much stronger than it is supposed to be. Automatic learning may even backfire completely and get the AI in a state where it does fine for the most part but breaks completely if you do one specific, maybe even very common thing.
Anecdotal evidence: some guys trained a neural network as a driving AI for a racing game. All went well on the training track. The network started to find its way along the course and did faster and faster laps. Then they took that AI and put it onto a new track. It did fine until it suddenly failed horribly and put the vehicle against the nearest wall. The developers finally figured out that there was some new, harmless object on the track that the AI wasn't trained to encounter. So it mistook it as an obstacle to avoid and did just that.
The SAP R/3 client from 2005/2006 was (supposedly) able to do messaging and emails. It was there in the UI but we didn't use it. I don't know about calender functionality. Wouldn't surprise me, though.
Learning AIs in games have been problematic in the past. Mostly it is about control over the experience that gets delivered to the customer: as a designer your job is to get it just right. You can do this easily with current more or less heuristic AI algorithms. The ability to learn opens the scope of possible behaviours so much that it's not possible anymore to deliver a guaranteed experience.
Short version: the designer can't stop the game from going nuts in unpredictable ways because of stupid player input (and well, all player input is "stupid").
They sell this stuff under the brand name Xeon Phi now. It's something like 60 simplified x86-like units on a die. Looks like they only cater to big orders from supercomputer builders right now.
Well, a tap on the Win key and the first few letters of the program I want beat your clicking through hierarchies every time. KDE introduced their sort-of equivalent minicli about a decade ago and I think that it's a terrific idea. I use these features regularly. And don't tell me they're slower than your mouse navigation. They aren't.
Hm, all those XNA and Unity based games that I've tried - all written using C# and therefore garbage collected - perform very smoothly here. OK, this is anecdotal evidence, but C# is so widely used in game development now that I have to assume that it really works. Otherwise, the engine makers would have changed programming language in an instant.
OK, then tell me why modern OpenGL drivers can provide the equivalent of all DirectX 11 features on Windows XP? The implementation of DirectX 10 and newer may not have been portable to XP, but the interface would have been. There are even libraries that translate DX10/DX11 to OpenGL!
Pushing a projection matrix to the GPU? For pixel-aligned 2D? Not necessary.:) I've got shaders running here that only need screen coordinates and textures as input.
Having said that, modern graphics cards are built completely around a 3D rendering pipeline to an extent where basically everything runs throuh the pipeline. And to the guy who claimed that modern GPUs are just some cores with texture units attached: you're wrong. There's a lot more specialized hardware around those shader cores (rasterizier, tesselator, hierarchical z buffer...). You're just not putting it to use if you're not using the pipeline.
One frame of latency? Only on CRTs. Modern games want to run at 60fps, that is 16ms per frame. Modern LCD screens do so much postprocessing on the video signal/image that it typically takes them at least 30 to 40ms to display that image on screen. Or as Mr. Carmack put it: "It's faster to send data packets across the atlantic than to display a frame on the screen" (QuakeCon 2012 keynote, quoted from memory)
UEFI is a monstrous specification that puts an almost fully featured single tasking OS into the mainboard firmware (memory management, file system, loading/linking, UI). At its core it is a good thing that cleans up much of the mess that the layered, hopelessly outdated legacy called BIOS has become. UEFI does away with things like boot blocks, the need for separate setup utilities embedded e.g. in RAID controller firmware and other stuff. The firmware can also be extended by modules placed next to the bootloaders in the same FAT partition. As far as I can remember, it can act as a boot menu for you if you cared to to register multiple bootloaders.
The list of features in this thing is incredibly long. I cannot comment on their actual quality, though. And complex specifications are hard to implement and even harder to get right. I have a feeling that this Samsung problem isn't the last UEFI problem we're going to see.
A lenticular lens array in front of LCD screens are a nice do-it-yourself solution that almost does the trick. It makes an autostereoscopic display that can display more than 2 images in different directions, making it possible to move around in front of the screen and see a stereo image without glasses. However, there are a couple of limitations. The LCD resolution suffers tremendously and the number of zones that you can create still isn't very high. Maybe it gets better with retina displays, but I'm not sure. Even paper printouts of 20 to 30 images at 600dpi are barely good enough.
Another interesting idea is this proposal: http://gl.ict.usc.edu/Research/LFD/ - replace each pixel on a *huge* screen with a microprojector acting as a directional light source. It is insane in its own special way, but this research group has successfully thrown massive amounts of hardware at problems in the past.
Don't dismiss what you see that easily. Sometimes there are perfectly good reasons why things came to be the way there are.
1. CCP practically invented Stackless Python, which is quite different from normal Python, although it retains the GIL 2. The core of EVE online was written in the late 90's. Multicores were not really on the radar back then. They became practical and affordable only years later. 3. Throwing away millions of lines of working code behind the company's single most important product (which was responsible for 1% of Iceland's' GDP last I checked) is not justifiable. 4. Nothing prevents you from starting multiple server processes on a single node as long as you have enough memory and network bandwidth left.
Granted, the inability of CPython to run truly concurrent threads would deter me from using it for applications requiring high performance. But 10 years ago I simply wouldn't have lost a single thought about concurrent threads. Would you?
PlasticLogic (http://plasticlogic.com) is working on a 20" display made out of 4 10" tiles that are (almost) rimless on two sides. I've contacted them about these panels and they promised availability around this January. Unfortunately I haven't had time to ask for an update yet... but this is definitely something to look out for. I'll be getting one of those if it is possible at all. However, PlasticLogic will almost certainly not sell finished displays, but panels and development kits for controlling them. So, unless someone else builds complete displays, you'll face some assembly.
Apple laptops are touch-enabled in some way: the touchpad in these machines takes basically the same kind of input as any smartphone or tablet. Only two things are really different: input is separated from the display in order to accommodate human physiology and it is primarily used to drive a cursor using relative input instead of absolute input. The latter could be changed in software, yet it doesn't make sense.
So, Apple understands touch interfaces so well that they've already been doing it properly on the big devices for many years.
Well, you could force everyone trying to compile your software to use your compiler, e.g. if you bootstrapped a custom, self-hosted programming language just for the cash register software. Then everyone trying to verify the binaries would have to use your compiler binary for the process, which automatically introduces the backdoor in every version of the software ever compiled.
However, a compiler for a useful new programming language takes time and effort, so from an economic perspective this shouldn't make sense.
As far as I remember the UEFI specification has some nice restrictions regarding to when key management can take place. I think that key management functionality of the firmware is basically blocked once the boot loader has been started. Thus, loading new keys must be performed in the firmware's own user interface, which is quite a safe option and far enough out of the way for most casual users. So pwning a system requires more social engineering than a malevolent download.
It's all there in the specification (which noone ever looks at, obviously) and the only question is how much will be implemented in practice. MS doesn't require the full specification for the Windows logo and manufacturers are always cutting corners to keep prices down.
Hibernation in Linux uses a swap partition. So depending on the size and usage of the swap space the key may be overwritten almost instantly or sit in swap space for eternity.
Hardware support isn't a good example. These guys really want to sell their fancy new electronics and the software changes are just a necessary inconvenience. With the Linux kernel developers taking any driver source code they can legally get their hands on and running with it, it's easy for hardware devs to write a first driver that's good enough to be accepted into the kernel and let others maintain it from there. With Windows you have to update your drivers for (almost) each new OS release that gets released. There's usually no other developer ready to do it for you without sending you the bill afterwards.
With good new software it's different. There are few OSS applications that started as open source and pioneered in some field. The more specific and specialized an application or tool gets, the less interest is there and the more the relevant OSS project(s) is out for just copying some of the good commercial software. I don't like to admit it, but in many fields the commercial software guys have the advantage and they push hard to keep it. For example, I haven't yet seen an OSS project that hired a couple of full time researchers in order to get an edge on the competition.
Have you read the Kotaku story? Newell expects 3rd party hardware specifically for Steam and its big screen mode; these would obviously be PCs. Their own hardware will be locked down, but you don't have to buy it.
Despite what all the others in this thread claim, the technology that you suggest has already been created. It's Google Native Client. They compile any code down to a x86 binary with some additional restrictions (for security - they're sandboxing the code) and this binary is then run inside a special environment that is the same regardless of the underlying operating system. It's even already deployed as a part of Chrome as far as I know and Bastion is a nice game that was ported to it.
Slashdot Mirror
No, game AIs will be designed by humans for a long time to come. The good ones are usually tuned very well to provide a very specific experience to the player. A big part of game design is to define this experience and behaviour. Automatic tuning risks altering the game in ways that deviate from the designer's intent too much and might make the game unplayable. The game may become too hard or too easy or the learning algorithm may decide to optimize the AI to exploit some obscure game rules or even a bug to become much stronger than it is supposed to be. Automatic learning may even backfire completely and get the AI in a state where it does fine for the most part but breaks completely if you do one specific, maybe even very common thing.
Anecdotal evidence: some guys trained a neural network as a driving AI for a racing game. All went well on the training track. The network started to find its way along the course and did faster and faster laps. Then they took that AI and put it onto a new track. It did fine until it suddenly failed horribly and put the vehicle against the nearest wall. The developers finally figured out that there was some new, harmless object on the track that the AI wasn't trained to encounter. So it mistook it as an obstacle to avoid and did just that.
The SAP R/3 client from 2005/2006 was (supposedly) able to do messaging and emails. It was there in the UI but we didn't use it. I don't know about calender functionality. Wouldn't surprise me, though.
When done for the first time? Yes.
Learning AIs in games have been problematic in the past. Mostly it is about control over the experience that gets delivered to the customer: as a designer your job is to get it just right. You can do this easily with current more or less heuristic AI algorithms. The ability to learn opens the scope of possible behaviours so much that it's not possible anymore to deliver a guaranteed experience.
Short version: the designer can't stop the game from going nuts in unpredictable ways because of stupid player input (and well, all player input is "stupid").
They sell this stuff under the brand name Xeon Phi now. It's something like 60 simplified x86-like units on a die. Looks like they only cater to big orders from supercomputer builders right now.
Well, a tap on the Win key and the first few letters of the program I want beat your clicking through hierarchies every time. KDE introduced their sort-of equivalent minicli about a decade ago and I think that it's a terrific idea. I use these features regularly. And don't tell me they're slower than your mouse navigation. They aren't.
And they did say something about that: https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf
Hm, all those XNA and Unity based games that I've tried - all written using C# and therefore garbage collected - perform very smoothly here. OK, this is anecdotal evidence, but C# is so widely used in game development now that I have to assume that it really works. Otherwise, the engine makers would have changed programming language in an instant.
OK, then tell me why modern OpenGL drivers can provide the equivalent of all DirectX 11 features on Windows XP? The implementation of DirectX 10 and newer may not have been portable to XP, but the interface would have been. There are even libraries that translate DX10/DX11 to OpenGL!
Cut that crap. Look at the list of Khronos Group member and tell me again that there is no interest in gaming with OpenGL!
And about multithreaded rendering: OpenGL absolutely *does* support it. It's just a model that's slightly different from DirectX.
Get a clue.
Pushing a projection matrix to the GPU? For pixel-aligned 2D? Not necessary. :) I've got shaders running here that only need screen coordinates and textures as input.
Having said that, modern graphics cards are built completely around a 3D rendering pipeline to an extent where basically everything runs throuh the pipeline. And to the guy who claimed that modern GPUs are just some cores with texture units attached: you're wrong. There's a lot more specialized hardware around those shader cores (rasterizier, tesselator, hierarchical z buffer...). You're just not putting it to use if you're not using the pipeline.
One frame of latency? Only on CRTs. Modern games want to run at 60fps, that is 16ms per frame. Modern LCD screens do so much postprocessing on the video signal/image that it typically takes them at least 30 to 40ms to display that image on screen. Or as Mr. Carmack put it: "It's faster to send data packets across the atlantic than to display a frame on the screen" (QuakeCon 2012 keynote, quoted from memory)
UEFI is a monstrous specification that puts an almost fully featured single tasking OS into the mainboard firmware (memory management, file system, loading/linking, UI). At its core it is a good thing that cleans up much of the mess that the layered, hopelessly outdated legacy called BIOS has become. UEFI does away with things like boot blocks, the need for separate setup utilities embedded e.g. in RAID controller firmware and other stuff. The firmware can also be extended by modules placed next to the bootloaders in the same FAT partition. As far as I can remember, it can act as a boot menu for you if you cared to to register multiple bootloaders.
The list of features in this thing is incredibly long. I cannot comment on their actual quality, though. And complex specifications are hard to implement and even harder to get right. I have a feeling that this Samsung problem isn't the last UEFI problem we're going to see.
A lenticular lens array in front of LCD screens are a nice do-it-yourself solution that almost does the trick. It makes an autostereoscopic display that can display more than 2 images in different directions, making it possible to move around in front of the screen and see a stereo image without glasses. However, there are a couple of limitations. The LCD resolution suffers tremendously and the number of zones that you can create still isn't very high. Maybe it gets better with retina displays, but I'm not sure. Even paper printouts of 20 to 30 images at 600dpi are barely good enough.
Another interesting idea is this proposal: http://gl.ict.usc.edu/Research/LFD/ - replace each pixel on a *huge* screen with a microprojector acting as a directional light source. It is insane in its own special way, but this research group has successfully thrown massive amounts of hardware at problems in the past.
Don't dismiss what you see that easily. Sometimes there are perfectly good reasons why things came to be the way there are.
1. CCP practically invented Stackless Python, which is quite different from normal Python, although it retains the GIL
2. The core of EVE online was written in the late 90's. Multicores were not really on the radar back then. They became practical and affordable only years later.
3. Throwing away millions of lines of working code behind the company's single most important product (which was responsible for 1% of Iceland's' GDP last I checked) is not justifiable.
4. Nothing prevents you from starting multiple server processes on a single node as long as you have enough memory and network bandwidth left.
Granted, the inability of CPython to run truly concurrent threads would deter me from using it for applications requiring high performance. But 10 years ago I simply wouldn't have lost a single thought about concurrent threads. Would you?
PlasticLogic (http://plasticlogic.com) is working on a 20" display made out of 4 10" tiles that are (almost) rimless on two sides. I've contacted them about these panels and they promised availability around this January. Unfortunately I haven't had time to ask for an update yet... but this is definitely something to look out for. I'll be getting one of those if it is possible at all. However, PlasticLogic will almost certainly not sell finished displays, but panels and development kits for controlling them. So, unless someone else builds complete displays, you'll face some assembly.
Apple laptops are touch-enabled in some way: the touchpad in these machines takes basically the same kind of input as any smartphone or tablet. Only two things are really different: input is separated from the display in order to accommodate human physiology and it is primarily used to drive a cursor using relative input instead of absolute input. The latter could be changed in software, yet it doesn't make sense.
So, Apple understands touch interfaces so well that they've already been doing it properly on the big devices for many years.
Well, you could force everyone trying to compile your software to use your compiler, e.g. if you bootstrapped a custom, self-hosted programming language just for the cash register software. Then everyone trying to verify the binaries would have to use your compiler binary for the process, which automatically introduces the backdoor in every version of the software ever compiled.
However, a compiler for a useful new programming language takes time and effort, so from an economic perspective this shouldn't make sense.
As far as I remember the UEFI specification has some nice restrictions regarding to when key management can take place. I think that key management functionality of the firmware is basically blocked once the boot loader has been started. Thus, loading new keys must be performed in the firmware's own user interface, which is quite a safe option and far enough out of the way for most casual users. So pwning a system requires more social engineering than a malevolent download.
It's all there in the specification (which noone ever looks at, obviously) and the only question is how much will be implemented in practice. MS doesn't require the full specification for the Windows logo and manufacturers are always cutting corners to keep prices down.
Are you sure about this? I never use hibernation and I have a hilberfil.sys in C:\ all the time unless I disable hibernation explicitly.
Hibernation in Linux uses a swap partition. So depending on the size and usage of the swap space the key may be overwritten almost instantly or sit in swap space for eternity.
Hardware support isn't a good example. These guys really want to sell their fancy new electronics and the software changes are just a necessary inconvenience. With the Linux kernel developers taking any driver source code they can legally get their hands on and running with it, it's easy for hardware devs to write a first driver that's good enough to be accepted into the kernel and let others maintain it from there. With Windows you have to update your drivers for (almost) each new OS release that gets released. There's usually no other developer ready to do it for you without sending you the bill afterwards.
With good new software it's different. There are few OSS applications that started as open source and pioneered in some field. The more specific and specialized an application or tool gets, the less interest is there and the more the relevant OSS project(s) is out for just copying some of the good commercial software. I don't like to admit it, but in many fields the commercial software guys have the advantage and they push hard to keep it. For example, I haven't yet seen an OSS project that hired a couple of full time researchers in order to get an edge on the competition.
Have you read the Kotaku story? Newell expects 3rd party hardware specifically for Steam and its big screen mode; these would obviously be PCs. Their own hardware will be locked down, but you don't have to buy it.
Despite what all the others in this thread claim, the technology that you suggest has already been created. It's Google Native Client. They compile any code down to a x86 binary with some additional restrictions (for security - they're sandboxing the code) and this binary is then run inside a special environment that is the same regardless of the underlying operating system. It's even already deployed as a part of Chrome as far as I know and Bastion is a nice game that was ported to it.
This is why all resources required to boot a newer windows system (e.g. the logo animation in Windows 7) are embedded in signed binaries as well.