Someone said NVIDIA is making a winning bet, because video cards will now need to deliver much higher frame rates, and thus the specs required to play games comfortably will be even higher. This is true.
However, 120 Hz doesn't mean you need your game to render at 120 FPS. It simply means you need to be able to display 120 images per second (60 per eye per second). Most likely, the implementation will involve using two frame buffers in the video card instead of one. The video card will render one frame for each eye, at whatever pace it can sustain. This rendering process will be decoupled from the display subsystem, which will simply have to switch to display the proper image for each eye at the right time. If the video card can't render at 120 FPS, then the video card can simply alternate between the same pair of left-right images until a new pair of images is done rendering.
Anyways, this is just speculation, but obviously, while 120 FPS is hard to maintain constantly on modern games, 60+ FPS will be more feasible. Some people might also be willing to reduce their display resolution so they can get a good enough frame rate for 3D play to be comfortable.
Many people seem concerned about the reading error rate. However, as it's been pointed out, it should be easy enough to read a DNA sequence multiple times (or read the whole genome multiple times) to decrease the error rate significantly. If you have one chip that can read the entire human genome in 30 mins, you can have the same chip read it twice in an hour, or four chips reading four copies in 30 mins.
Furthermore, if you're using a technique like this to map a person's genome, you can be clever about it. Base pairs code genes, which is something you can take into account. For example, if you're reading the eye color gene, and your machine somehow consistently makes mistakes in that area, you can compare your reads to the few possible known eye color genes, and pick the most likely based on the genetic sequences of the entire gene.
As someone who has experience developing game engines, I can tell you it makes more sense to have multiple AI threads, multiple physics threads, multiple rendering threads, etc... Rather than trying to see each of these as monolitic tasks where you have "the AI threads" and "the physics thread", etc... As I often see people suggesting.
There are a few reasons for this, but among other things:
1) It's easier to coordinate 2 physics threads than a physics thread and an AI thread, because they both affect the game state in different ways, and should ideally be developed mostly in isolation.
2) The workload is not even between very different tasks like AI and physics. However, if you split the physics workload into 2 threads, you can usually achieve a more even work distribution between the two threads.
I know the guy, he posts on societyofrobots, a robotics forum I used to frequent. Unfortunately, I have to call rubbish on this one. I don't think he knows much about AI. He claims all sorts of incredible things that his robot supposedly does that are all far beyond what anyone has done in robotics, vision or AI as a whole, but never elaborates on how he did it, and discusses design issues that should, in practice, be non-issues.
"I am what you called a mad scientist.
I don:t believe any documentation, No blue print, No paperwork, No Cad.
I have build 12+ large robots (main robots) none of which has any documentation or blue print...
Even the software has NO documentation.
The software is about 3Gig and I think I have about 15 lines of comments.
The typical variable name I used are....
X, X1,X2, A1,A2,AA1,AA2,AAA1,AAA2 etc..."
Slashdot Mirror
Except they'll call it WD4X or something to avoid getting sued!
Someone said NVIDIA is making a winning bet, because video cards will now need to deliver much higher frame rates, and thus the specs required to play games comfortably will be even higher. This is true.
However, 120 Hz doesn't mean you need your game to render at 120 FPS. It simply means you need to be able to display 120 images per second (60 per eye per second). Most likely, the implementation will involve using two frame buffers in the video card instead of one. The video card will render one frame for each eye, at whatever pace it can sustain. This rendering process will be decoupled from the display subsystem, which will simply have to switch to display the proper image for each eye at the right time. If the video card can't render at 120 FPS, then the video card can simply alternate between the same pair of left-right images until a new pair of images is done rendering.
Anyways, this is just speculation, but obviously, while 120 FPS is hard to maintain constantly on modern games, 60+ FPS will be more feasible. Some people might also be willing to reduce their display resolution so they can get a good enough frame rate for 3D play to be comfortable.
Many people seem concerned about the reading error rate. However, as it's been pointed out, it should be easy enough to read a DNA sequence multiple times (or read the whole genome multiple times) to decrease the error rate significantly. If you have one chip that can read the entire human genome in 30 mins, you can have the same chip read it twice in an hour, or four chips reading four copies in 30 mins.
Furthermore, if you're using a technique like this to map a person's genome, you can be clever about it. Base pairs code genes, which is something you can take into account. For example, if you're reading the eye color gene, and your machine somehow consistently makes mistakes in that area, you can compare your reads to the few possible known eye color genes, and pick the most likely based on the genetic sequences of the entire gene.
This is a small point, but...
As someone who has experience developing game engines, I can tell you it makes more sense to have multiple AI threads, multiple physics threads, multiple rendering threads, etc... Rather than trying to see each of these as monolitic tasks where you have "the AI threads" and "the physics thread", etc... As I often see people suggesting.
There are a few reasons for this, but among other things:
1) It's easier to coordinate 2 physics threads than a physics thread and an AI thread, because they both affect the game state in different ways, and should ideally be developed mostly in isolation.
2) The workload is not even between very different tasks like AI and physics. However, if you split the physics workload into 2 threads, you can usually achieve a more even work distribution between the two threads.
I know the guy, he posts on societyofrobots, a robotics forum I used to frequent. Unfortunately, I have to call rubbish on this one. I don't think he knows much about AI. He claims all sorts of incredible things that his robot supposedly does that are all far beyond what anyone has done in robotics, vision or AI as a whole, but never elaborates on how he did it, and discusses design issues that should, in practice, be non-issues.
Link to his thread on that forum: http://www.societyofrobots.com/robotforum/index.php?topic=1335.0
A quote of interest, from the robot's creator:
"I am what you called a mad scientist. I don:t believe any documentation, No blue print, No paperwork, No Cad. I have build 12+ large robots (main robots) none of which has any documentation or blue print...
Even the software has NO documentation. The software is about 3Gig and I think I have about 15 lines of comments. The typical variable name I used are.... X, X1,X2, A1,A2,AA1,AA2,AAA1,AAA2 etc..."