What bugs me the most about the sword controls is that if Link's sword is put away, swinging the Wiimote doesn't even attack. It merely causes Link to unsheathe his sword. When that interface was a button, it wasn't too annoying, but when I swing the Wiimote I want Link to swing his sword, dangit! It's also much more annoying now when you enter an area where Link refuses to attack, and you swing the Wiimote wildly to no effect. It really reminds you that you're not swinging a sword in an epic adventure; you're just flailing around with a little plastic thing sitting on your couch.
I'm not talking about installing it automatically. I'm talking about a way to package C# applications such that merely executing them does not require the.NET framework to be installed. There's no reason simply running a program written in the C# language should require poking around in system directories and installing crap into the OS. Of course, every program packaged this way would have its own separate copy of the runtime. But they wouldn't need the whole framework, they could just bring the (small) parts they need. IMHO that little duplication is a small price to pay for what you get. And not every program would be packaged this way, only ones that need to run without an install.
I second the suggestion to look at Model-View-Controller. It is not always clear how code should be separated to fit the pattern, and it's not always possible or desirable to separate the three parts to the point where each part could be modularly swapped out. But maintaining a healthy amount of separation, especially between the model and the view, will definitely result in a more flexible and easier to maintain application.
Have you tried Visual Studio 2005 with Windows Forms 2.0? It is much improved over 2003/Windows Forms 1.0, especially so in the layout department. Its only major lacking feature is the tear-away panels ironically used to such great effect in the Visual Studio IDE itself. Well, that and a concept of "action" to tie together menu items, keyboard shortcuts, undo/redo, and scriptable actions. And in general a simple way to implement proper separation between Model, View, and Controller in a modern application. But I'm not sure anyone's got that completely right in a GUI framework yet, even Trolltech.
Generics, for instance, are a much-needed feature - but Microsoft didn't bother to implement it for ArrayList, the data structure that I use most often.
ArrayList is still its original, non-generic self for compatibility reasons, but the new List<> class is its excellent replacement in the System.Collections.Generic namespace, along with the generic Hashtable replacement, Dictionary<,>. Don't know why they felt the need to change the names, although ArrayList->List was an improvement...
Other than that, I agree. I'd just put events and delegates farther down under the "completely suck" section. They were really botched and it makes certain things a lot harder than they should be. Also, I'd mention the single greatest thing about C#, IMHO its saving grace: C/C++ interop. The design of the interop with legacy code is nothing short of brilliant. It's five minutes work to wrap and call a random C function, no matter if it takes pointers to weird structs or even a callback! And because of that, C# actually stands a chance of displacing C++ as the language of choice for Windows applications.
If only Microsoft had fixed it to allow distributing C# applications with their own stripped-down runtime included, instead of requiring administrative install of the full 20+ MB.NET Framework including ASP.NET and who all knows what crap you don't need, it probably would have replaced C++ for many applications already. Something like perl2exe for C# is what I want. Just bundle the runtime and the JIT and your code up in one nice tidy ready-to-run executable. That would do wonders for the adoption of C#.
No, they are hoping to make it up two years from now when the PS3 is still selling like hotcakes but it costs $400 less to make. But in order for that to happen, they need good games. And for good games to be released two years from now, they need to already be in development. But for people to start developing games, they need to know there will be a market to sell them. So Sony has to start selling PS3s now, no matter what the cost, to produce a market for the games that will drive PS3 purchases years from now when it's finally profitable to sell them.
I highly doubt AMD is planning on using combined CPU/GPU solutions on their mainstream desktop parts, and they are absolutely not going to do so for server parts
I think they are, and I think it's the right choice. The GPU that will be integrated will not be today's GPU, but a much more general processor. Look at NVidia's G80 for the beginning of this trend; they're adding non-graphics-oriented features like integer math, bitwise operations, and soon double-precision floating point. G80 has 128 (!) fully general-purpose SISD (not SIMD) cores, and soon with their CUDA API you will be able to run C code on them directly instead of hacking it up through DirectX or OpenGL.
AMD's Fusion will likely look a lot more like a Cell processor than, say, Opteron + X1900 on the same die. ATI is very serious about doing more than graphics: look at their CTM initiative (now in closed beta); they are doing the previously unthinkable and publishing the *machine language* for their shader engines! They want businesses to adopt this in a big way. And it makes a lot of sense: with a GPU this close to the CPU, you can start accelerating tons of things, from scientific calculations to SQL queries. Basically *anything* that is parallelizable can benefit.
I see this as nothing less than the future of desktop processors. One or two x86 cores for legacy code, and literally hundreds of simpler cores for sheer calculation power. Forget about games, this is much bigger than that. These chips will do things that are simply impossible for today's processors. AMD and Intel should both be jumping to implement this new paradigm, because it sets the stage for a whole new round of increasing performance and hardware upgrades. The next few years will be an exciting time for the processor business.
Honestly, Sony should sell those PS3s at the price people are actually willing to pay, i.e. much more than retail, instead of failing miserably to prevent anarchy. Setting the correct price, from an economics point of view, would be best done by auction. This leads us to the conclusion that Sony should cut out the middlemen by EBaying the first few batches of PS3s themselves.
Unfortunately it won't happen because Sony would probably be crucified by the media for allowing people to pay as much as they want for PS3s. People hate the very idea that rich people can get an advantage from their wealth and so would rather dole out PS3s at the front of long lines to unemployed losers with too much time on their hands. Which ironically results in them ending up on EBay anyway, sold to the highest-bidding rich guy. You can fight against economics but you can't win.
I'm not arguing against procedural textures in general; they are the future of the game industry for sure. I'm arguing against calculating them on-the-fly in pixel shaders as opposed to precomputing them at load time and storing them as bitmaps in texture memory. That doesn't prevent you from using procedural textures to provide variation. You are slightly constrained in how much variation you can show at once by texture memory, but it's not a huge restriction considering how big texture memory is nowadays (since it often has to hold an entire level's worth of non-procedural high-resolution textures because it takes too long to load them and only one resolution is available to load).
Your analogy is spurious, and your "answer" isn't convincing. Care to explain what exactly makes a per-pixel procedural texture "look better" than one precomputed with sufficient resolution (but still procedural), when you can spend 100+ times more processing power on the precomputed one?
I can see per-pixel procedural textures being useful if the texture is changing rapidly. But for the vast majority of textures, precomputing makes so much more sense. It allows you to do computations that simply aren't feasible to do per-pixel.
You are quite mistaken if you think that's how people are proposing to use procedural textures in games in the next few years. It's all "generate bitmap in main memory, upload texture to graphics card" right now. Per-pixel procedural textures for realtime graphics are a long way off.
Personally, I'm not sure it will ever make sense to do per-pixel procedural textures. Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames? That way you can use hundreds of times more processing power per generated texture pixel and get nicer textures. You can still get the benefits of reduced storage for textures you don't currently need on screen, and you can still get the benefits of being able to generate any resolution texture you want. As long as texture memory is big enough to hold all the textures you need for a few frames at once, there's little downside.
There is no reason the set of functions used to generate the procedural texture couldn't be exactly the tools that Photoshop provides, and the arguments to those functions the mouse movements and other inputs the artist gives to Photoshop. Then Photoshop would be exactly the right interface for constructing procedural textures.
Basically you would just save out the entire Photoshop undo history to a file and use it later to reconstruct the image. Of course, unless you're Adobe, reconstructing the image would require reimplementing Photoshop. But perhaps the GIMP or Krita could be modified in this manner.
I would be very interested in seeing how large an image constructed in this manner would be and how fast the reconstruction could take place. It would be possible to take so many actions in painting an image that the procedural description would be longer than the output bitmap. But I have a hunch that for most images that would not be the case. Artists could also deliberately use painting styles that are more efficient.
OpenGL Extensions are not nearly the same thing as DirectX Caps. Vendors can't add new DirectX caps; they can only choose to implement, or not, the caps that Micosoft defines. For an example of why this sucks, consider geometry instancing. Microsoft decided in their infinite wisdom that only Shader Model 3.0 cards could have geometry instancing support. Then when ATI produced some Shader Model 2 cards with instancing they had to disable it by default and use a terrible hack to enable it involving calling an unrelated API (CheckDeviceFormat IIRC) with a special "magic number", just to pass Windows Logo testing.
For another example, consider the sad, sad state of dual-head support in DirectX. To this day it is impossible to write a windowed (non-fullscreen) DirectX application that performs well when stretched across two monitors as seen by Windows. Graphics vendors have stood on their heads and worked around this problem by telling Windows that there is really only one monitor and replacing all the dual-head code in Windows with logic in the graphics driver! Meanwhile, OpenGL works flawlessly.
In any case, DirectX Caps suck so much that developers often ignore them in favor of just using the make and model of card to determine a suitable rendering path. Microsoft realizes this, and that's why the role of caps has been reduced in DirectX 10. That's right: DirectX 10 mostly defines a standard set of features that every card must support, leaving very little flexibility for vendors.
I'm not sure how anyone could argue that DirectX is friendlier to the development of new graphics features than OpenGL. There's simply no way to add new features to it at all, unless you are Microsoft. Everyone has to wait, for years, until Microsoft comes down from Mount Sinai with the next version set in stone. Or, as has become the status quo: implement new features using dirty hacks, and do handstands to hide these new features from Microsoft's APIs until DirectX catches up.
Site authors publishing XSL for their feeds clearly think differently.
And the people actually using the sites? What do they think? After all, they're the ones choosing (or not) to use Firefox.
What happens if a publisher uses XSLT to display ads in the HTMLized version of their feed?
Personally, I'd be pretty happy if Firefox's feed pretty-printing resulted in ad-blocking too. Bonus! Same arguments as pop-up blocking here.
If cranky authors win this war, it will be a step back for the web. RSS is for *syndication*, not presentation, and user agents should be able to format it as they see fit to provide a consistent user experience for subscription services. If you want to present an explicit visual rendering of markup, serve XHTML+CSS. And if you wasted your time implementing a feature that was obviously going to be rolled into the next generation of browsers, boo hoo for you; time to move on.
What I hate the most is attempting to search for free software for a particular task (not knowing the name of the free software in advance). The links are always spammed up with crappy $29.95 shareware programs instead of the high-quality free alternative that you know exists somewhere.
For example, try a Google search for "Palm dictionary". Adding things like "+free -buy -shareware" doesn't really help. In my case, I happened to know that WordNet was a good keyword to add to the search and eventually found this. But back in the day, before Google spam, that site would have been Google's first hit for "palm dictionary". My mom, never having heard of WordNet, was almost ready to buy a shareware dictionary since that was all she could find.
Everyone is comparing creating one 30-second special effect with assembling a $200 million 140-minute live-action feature film. These are two completely different jobs. Has nobody noticed that his showreel includes basically zero footage of *actors*? Sure, his special effects shots are second to none, but that's a function of the special effects studio as much if not more than the director. Even Alive in Joburg is just a collection of special-effects shots; plot is thin and acting is limited to motion-capture.
For all we know, this guy could be as bad at directing live actors as George Lucas! If I had $200 million, I wouldn't spend it on a feature film directed by this guy until I'd seen at least a few tens of minutes of footage featuring real actors and a plot. (Though if I wanted an edgy commercial featuring photoreal special effects, I'd have no problem hiring him. That Citroen commercial was sweet.)
Note, however: interpreting the results will be difficult, and *really* tricky code could defeat it anyway. Actually cleaning the infection is probably impractical, and certainly not worth your time unless your aim is to become intimately familiar with the bowels of Windows.
Seriously. Sony's been getting terrible press over every aspect of PS3 for months now, with all the signs pointing toward a much smaller market share this generation. There are supply problems, price problems, unimpressive games, lack of rumble in the controller, and a complete lack of a demonstrated credible competitor to XBox Live. Then the stock decides to drop because a couple of kiosks with prerelease hardware overheated at a trade show? Somebody's stupid here; either it's the traders or the analysts.
Yeah, this thing would be perfect for supplying a moonbase. We could cheaply launch tons of raw materials, food, and oxygen into orbit along with rocket fuel, and a few robotic ferries could make runs shipping them to the moon.
Video processing is why consumers will eventually want 80-core chips. Many video algorithms are extremely parallelizable. Heck, modern video cards have double-digit numbers of shader units already, and consumers buy them. Generating video images in real-time is extremely parallelizable. Software rasterizers could easily use 80 cores. More excitingly, real-time raytracing would be feasible with 80 cores; no video card required. HD videos tax modern single cores just when being decoded, and encoding is glacially slow. Both are easily parallelizable to 80 cores and both will be demanded by consumers in the future.
Personally, I also believe that the people blaming software for the failures of AI are wrong, and that multi-core computing will also finally enable some interesting applications like usefully robust speech recognition, object recognition in images, 3D reconstructions from video footage, stereo-vision-based navigation for robots, and other cool stuff we haven't thought of yet. All that's still a little farther out though.
Nobody complains about having lots of gameplay. What they complain about is being forced to complete gameplay to unlock major game features like multiplayer, or being forced to go through every last bit of gameplay before getting closure for the story. It's as if the game designers realize that nobody would choose to do their chores if they weren't necessary to unlock the rest of a 40-hour time investment.
A good game shouldn't be a chore that you slog through to unlock things. Tetris and Pac-Man are good examples of games you play because they're *fun*, not because you need to unlock something to justify the $50 and 40 hours you've already spent. You play them until you're bored and then you stop.
Zelda has always been a story-driven game but it includes plenty of optional side quests that can easily be double or triple the length of the main story, if you're interested. GTA is another example. Zelda and GTA both include many unlockables, but more often than not I find myself doing the challenges because they're *fun*, not because I need the unlockable thing. And the ones I don't find fun (finding all 100 hidden packages), I don't do.
To me, tens of millions sounds like a gross underestimate. Every view of every video containing even a small piece of a copyrighted song is an infringement, possibly multiplied because the video could be downloaded and redistributed. Using the same math they use on P2P infringers, I could easily see the calculated damages being in the billions or trillions. The revenue YouTube actually makes is immaterial to the calculation of damages.
The music companies want to sound reasonable so they quote a figure that YouTube might actually be able to pay. If they quoted the real figure people might catch on to just how unreasonable current law is.
Ignoring the real exchange rate, Nintendo's exchange rate in previous console releases has consistently been 25000 yen = $200. The SNES, N64, and GameCube all launched with this pair of prices.
However, the Japanese Wii doesn't include pack-in Wii Sports. If the NYT is correct (long shot; release prior to Japan?!?), perhaps the American launch is going to be somewhat different. Here's hoping that extra $50 gets us both Wii Sports *and* a second controller out of the box to play it with. That would be worth the difference.
Slashdot Mirror
What bugs me the most about the sword controls is that if Link's sword is put away, swinging the Wiimote doesn't even attack. It merely causes Link to unsheathe his sword. When that interface was a button, it wasn't too annoying, but when I swing the Wiimote I want Link to swing his sword, dangit! It's also much more annoying now when you enter an area where Link refuses to attack, and you swing the Wiimote wildly to no effect. It really reminds you that you're not swinging a sword in an epic adventure; you're just flailing around with a little plastic thing sitting on your couch.
I'm not talking about installing it automatically. I'm talking about a way to package C# applications such that merely executing them does not require the .NET framework to be installed. There's no reason simply running a program written in the C# language should require poking around in system directories and installing crap into the OS. Of course, every program packaged this way would have its own separate copy of the runtime. But they wouldn't need the whole framework, they could just bring the (small) parts they need. IMHO that little duplication is a small price to pay for what you get. And not every program would be packaged this way, only ones that need to run without an install.
I second the suggestion to look at Model-View-Controller. It is not always clear how code should be separated to fit the pattern, and it's not always possible or desirable to separate the three parts to the point where each part could be modularly swapped out. But maintaining a healthy amount of separation, especially between the model and the view, will definitely result in a more flexible and easier to maintain application.
Have you tried Visual Studio 2005 with Windows Forms 2.0? It is much improved over 2003/Windows Forms 1.0, especially so in the layout department. Its only major lacking feature is the tear-away panels ironically used to such great effect in the Visual Studio IDE itself. Well, that and a concept of "action" to tie together menu items, keyboard shortcuts, undo/redo, and scriptable actions. And in general a simple way to implement proper separation between Model, View, and Controller in a modern application. But I'm not sure anyone's got that completely right in a GUI framework yet, even Trolltech.
Generics, for instance, are a much-needed feature - but Microsoft didn't bother to implement it for ArrayList, the data structure that I use most often.
.NET Framework including ASP.NET and who all knows what crap you don't need, it probably would have replaced C++ for many applications already. Something like perl2exe for C# is what I want. Just bundle the runtime and the JIT and your code up in one nice tidy ready-to-run executable. That would do wonders for the adoption of C#.
ArrayList is still its original, non-generic self for compatibility reasons, but the new List<> class is its excellent replacement in the System.Collections.Generic namespace, along with the generic Hashtable replacement, Dictionary<,>. Don't know why they felt the need to change the names, although ArrayList->List was an improvement...
Other than that, I agree. I'd just put events and delegates farther down under the "completely suck" section. They were really botched and it makes certain things a lot harder than they should be. Also, I'd mention the single greatest thing about C#, IMHO its saving grace: C/C++ interop. The design of the interop with legacy code is nothing short of brilliant. It's five minutes work to wrap and call a random C function, no matter if it takes pointers to weird structs or even a callback! And because of that, C# actually stands a chance of displacing C++ as the language of choice for Windows applications.
If only Microsoft had fixed it to allow distributing C# applications with their own stripped-down runtime included, instead of requiring administrative install of the full 20+ MB
No, they are hoping to make it up two years from now when the PS3 is still selling like hotcakes but it costs $400 less to make. But in order for that to happen, they need good games. And for good games to be released two years from now, they need to already be in development. But for people to start developing games, they need to know there will be a market to sell them. So Sony has to start selling PS3s now, no matter what the cost, to produce a market for the games that will drive PS3 purchases years from now when it's finally profitable to sell them.
I highly doubt AMD is planning on using combined CPU/GPU solutions on their mainstream desktop parts, and they are absolutely not going to do so for server parts
I think they are, and I think it's the right choice. The GPU that will be integrated will not be today's GPU, but a much more general processor. Look at NVidia's G80 for the beginning of this trend; they're adding non-graphics-oriented features like integer math, bitwise operations, and soon double-precision floating point. G80 has 128 (!) fully general-purpose SISD (not SIMD) cores, and soon with their CUDA API you will be able to run C code on them directly instead of hacking it up through DirectX or OpenGL.
AMD's Fusion will likely look a lot more like a Cell processor than, say, Opteron + X1900 on the same die. ATI is very serious about doing more than graphics: look at their CTM initiative (now in closed beta); they are doing the previously unthinkable and publishing the *machine language* for their shader engines! They want businesses to adopt this in a big way. And it makes a lot of sense: with a GPU this close to the CPU, you can start accelerating tons of things, from scientific calculations to SQL queries. Basically *anything* that is parallelizable can benefit.
I see this as nothing less than the future of desktop processors. One or two x86 cores for legacy code, and literally hundreds of simpler cores for sheer calculation power. Forget about games, this is much bigger than that. These chips will do things that are simply impossible for today's processors. AMD and Intel should both be jumping to implement this new paradigm, because it sets the stage for a whole new round of increasing performance and hardware upgrades. The next few years will be an exciting time for the processor business.
Honestly, Sony should sell those PS3s at the price people are actually willing to pay, i.e. much more than retail, instead of failing miserably to prevent anarchy. Setting the correct price, from an economics point of view, would be best done by auction. This leads us to the conclusion that Sony should cut out the middlemen by EBaying the first few batches of PS3s themselves.
Unfortunately it won't happen because Sony would probably be crucified by the media for allowing people to pay as much as they want for PS3s. People hate the very idea that rich people can get an advantage from their wealth and so would rather dole out PS3s at the front of long lines to unemployed losers with too much time on their hands. Which ironically results in them ending up on EBay anyway, sold to the highest-bidding rich guy. You can fight against economics but you can't win.
I'm not arguing against procedural textures in general; they are the future of the game industry for sure. I'm arguing against calculating them on-the-fly in pixel shaders as opposed to precomputing them at load time and storing them as bitmaps in texture memory. That doesn't prevent you from using procedural textures to provide variation. You are slightly constrained in how much variation you can show at once by texture memory, but it's not a huge restriction considering how big texture memory is nowadays (since it often has to hold an entire level's worth of non-procedural high-resolution textures because it takes too long to load them and only one resolution is available to load).
Your analogy is spurious, and your "answer" isn't convincing. Care to explain what exactly makes a per-pixel procedural texture "look better" than one precomputed with sufficient resolution (but still procedural), when you can spend 100+ times more processing power on the precomputed one?
I can see per-pixel procedural textures being useful if the texture is changing rapidly. But for the vast majority of textures, precomputing makes so much more sense. It allows you to do computations that simply aren't feasible to do per-pixel.
You are quite mistaken if you think that's how people are proposing to use procedural textures in games in the next few years. It's all "generate bitmap in main memory, upload texture to graphics card" right now. Per-pixel procedural textures for realtime graphics are a long way off.
Personally, I'm not sure it will ever make sense to do per-pixel procedural textures. Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames? That way you can use hundreds of times more processing power per generated texture pixel and get nicer textures. You can still get the benefits of reduced storage for textures you don't currently need on screen, and you can still get the benefits of being able to generate any resolution texture you want. As long as texture memory is big enough to hold all the textures you need for a few frames at once, there's little downside.
There is no reason the set of functions used to generate the procedural texture couldn't be exactly the tools that Photoshop provides, and the arguments to those functions the mouse movements and other inputs the artist gives to Photoshop. Then Photoshop would be exactly the right interface for constructing procedural textures.
Basically you would just save out the entire Photoshop undo history to a file and use it later to reconstruct the image. Of course, unless you're Adobe, reconstructing the image would require reimplementing Photoshop. But perhaps the GIMP or Krita could be modified in this manner.
I would be very interested in seeing how large an image constructed in this manner would be and how fast the reconstruction could take place. It would be possible to take so many actions in painting an image that the procedural description would be longer than the output bitmap. But I have a hunch that for most images that would not be the case. Artists could also deliberately use painting styles that are more efficient.
OpenGL Extensions are not nearly the same thing as DirectX Caps. Vendors can't add new DirectX caps; they can only choose to implement, or not, the caps that Micosoft defines. For an example of why this sucks, consider geometry instancing. Microsoft decided in their infinite wisdom that only Shader Model 3.0 cards could have geometry instancing support. Then when ATI produced some Shader Model 2 cards with instancing they had to disable it by default and use a terrible hack to enable it involving calling an unrelated API (CheckDeviceFormat IIRC) with a special "magic number", just to pass Windows Logo testing.
For another example, consider the sad, sad state of dual-head support in DirectX. To this day it is impossible to write a windowed (non-fullscreen) DirectX application that performs well when stretched across two monitors as seen by Windows. Graphics vendors have stood on their heads and worked around this problem by telling Windows that there is really only one monitor and replacing all the dual-head code in Windows with logic in the graphics driver! Meanwhile, OpenGL works flawlessly.
In any case, DirectX Caps suck so much that developers often ignore them in favor of just using the make and model of card to determine a suitable rendering path. Microsoft realizes this, and that's why the role of caps has been reduced in DirectX 10. That's right: DirectX 10 mostly defines a standard set of features that every card must support, leaving very little flexibility for vendors.
I'm not sure how anyone could argue that DirectX is friendlier to the development of new graphics features than OpenGL. There's simply no way to add new features to it at all, unless you are Microsoft. Everyone has to wait, for years, until Microsoft comes down from Mount Sinai with the next version set in stone. Or, as has become the status quo: implement new features using dirty hacks, and do handstands to hide these new features from Microsoft's APIs until DirectX catches up.
Personally, I'd be pretty happy if Firefox's feed pretty-printing resulted in ad-blocking too. Bonus! Same arguments as pop-up blocking here.
If cranky authors win this war, it will be a step back for the web. RSS is for *syndication*, not presentation, and user agents should be able to format it as they see fit to provide a consistent user experience for subscription services. If you want to present an explicit visual rendering of markup, serve XHTML+CSS. And if you wasted your time implementing a feature that was obviously going to be rolled into the next generation of browsers, boo hoo for you; time to move on.
Yes.
See also -inurl:(foo|bar|baz) as used to great effect by Give Me Back My Google.
To be fair, this new service is a much better way of going about these things.
What I hate the most is attempting to search for free software for a particular task (not knowing the name of the free software in advance). The links are always spammed up with crappy $29.95 shareware programs instead of the high-quality free alternative that you know exists somewhere.
For example, try a Google search for "Palm dictionary". Adding things like "+free -buy -shareware" doesn't really help. In my case, I happened to know that WordNet was a good keyword to add to the search and eventually found this. But back in the day, before Google spam, that site would have been Google's first hit for "palm dictionary". My mom, never having heard of WordNet, was almost ready to buy a shareware dictionary since that was all she could find.
Everyone is comparing creating one 30-second special effect with assembling a $200 million 140-minute live-action feature film. These are two completely different jobs. Has nobody noticed that his showreel includes basically zero footage of *actors*? Sure, his special effects shots are second to none, but that's a function of the special effects studio as much if not more than the director. Even Alive in Joburg is just a collection of special-effects shots; plot is thin and acting is limited to motion-capture.
For all we know, this guy could be as bad at directing live actors as George Lucas! If I had $200 million, I wouldn't spend it on a feature film directed by this guy until I'd seen at least a few tens of minutes of footage featuring real actors and a plot. (Though if I wanted an edgy commercial featuring photoreal special effects, I'd have no problem hiring him. That Citroen commercial was sweet.)
Try this: RootkitRevealer
Note, however: interpreting the results will be difficult, and *really* tricky code could defeat it anyway. Actually cleaning the infection is probably impractical, and certainly not worth your time unless your aim is to become intimately familiar with the bowels of Windows.
Seriously. Sony's been getting terrible press over every aspect of PS3 for months now, with all the signs pointing toward a much smaller market share this generation. There are supply problems, price problems, unimpressive games, lack of rumble in the controller, and a complete lack of a demonstrated credible competitor to XBox Live. Then the stock decides to drop because a couple of kiosks with prerelease hardware overheated at a trade show? Somebody's stupid here; either it's the traders or the analysts.
Yeah, this thing would be perfect for supplying a moonbase. We could cheaply launch tons of raw materials, food, and oxygen into orbit along with rocket fuel, and a few robotic ferries could make runs shipping them to the moon.
Well, we could send up milkshakes and soup. Nobody said astronouts would get to eat gourmet food...
Video processing is why consumers will eventually want 80-core chips. Many video algorithms are extremely parallelizable. Heck, modern video cards have double-digit numbers of shader units already, and consumers buy them. Generating video images in real-time is extremely parallelizable. Software rasterizers could easily use 80 cores. More excitingly, real-time raytracing would be feasible with 80 cores; no video card required. HD videos tax modern single cores just when being decoded, and encoding is glacially slow. Both are easily parallelizable to 80 cores and both will be demanded by consumers in the future.
Personally, I also believe that the people blaming software for the failures of AI are wrong, and that multi-core computing will also finally enable some interesting applications like usefully robust speech recognition, object recognition in images, 3D reconstructions from video footage, stereo-vision-based navigation for robots, and other cool stuff we haven't thought of yet. All that's still a little farther out though.
Nobody complains about having lots of gameplay. What they complain about is being forced to complete gameplay to unlock major game features like multiplayer, or being forced to go through every last bit of gameplay before getting closure for the story. It's as if the game designers realize that nobody would choose to do their chores if they weren't necessary to unlock the rest of a 40-hour time investment.
A good game shouldn't be a chore that you slog through to unlock things. Tetris and Pac-Man are good examples of games you play because they're *fun*, not because you need to unlock something to justify the $50 and 40 hours you've already spent. You play them until you're bored and then you stop.
Zelda has always been a story-driven game but it includes plenty of optional side quests that can easily be double or triple the length of the main story, if you're interested. GTA is another example. Zelda and GTA both include many unlockables, but more often than not I find myself doing the challenges because they're *fun*, not because I need the unlockable thing. And the ones I don't find fun (finding all 100 hidden packages), I don't do.
To me, tens of millions sounds like a gross underestimate. Every view of every video containing even a small piece of a copyrighted song is an infringement, possibly multiplied because the video could be downloaded and redistributed. Using the same math they use on P2P infringers, I could easily see the calculated damages being in the billions or trillions. The revenue YouTube actually makes is immaterial to the calculation of damages.
The music companies want to sound reasonable so they quote a figure that YouTube might actually be able to pay. If they quoted the real figure people might catch on to just how unreasonable current law is.
Ignoring the real exchange rate, Nintendo's exchange rate in previous console releases has consistently been 25000 yen = $200. The SNES, N64, and GameCube all launched with this pair of prices.
However, the Japanese Wii doesn't include pack-in Wii Sports. If the NYT is correct (long shot; release prior to Japan?!?), perhaps the American launch is going to be somewhat different. Here's hoping that extra $50 gets us both Wii Sports *and* a second controller out of the box to play it with. That would be worth the difference.