I can't speak for the chip yet, but I've read the papers on their software system and know that it gets a good part of its speed by rendering triangles only. The secret is that they have a cleverly laid-out, cache-friendly BSP tree of the triangles and their code uses MMX SIMD instruction to intersect 4 rays at a time with the triangles in the tree. Rendering triangles only lets them get away with a more compact (and therefore more cache friendly) memory structure and lets them avoid the performance penalty of switching or [vtable] dispatching on object types -- it's all one very tight loop to walk the tree and intersect triangles.
How about non-tesselated geometry? You can have high detail curved surfaces without turning everything into a dense polygon mesh. That in turn lowers the memory and rendering requirements so you can apply those resources to proper detail instead.
Or how about global illumination lighting effects? Truely emissive surfaces and area lights? As a hobbyist map maker, I would kill to have an engine that supported these; imagine being able to just tag the sky as an emmisive surface and have the entire level lit up and shadowed accordingly without having to painstakingly add bounce lights everywhere and tune them till they looked correct.
Another good argument that I've heard is based on the complexity of the algorithms. GPU style rendering is inherently order O(n) on the number of items in the scene. While ray-tracing has a high constant factor, a good ray tracing acceleration structure makes the problem O(log n) -- as the scene grows the time to ray trace gets closer to the time to GPU render it. Admittely you can do much the same with the GPU: there's a lot of stuff like BSP trees and bounding volume heirarchies and frustrum culling that you can do to speed it up, but then you're already applying ray-tracing techniques anyway, and now you're really talking about something that's more of a hybrid with the CPU just doing the ray-tracing part.
There's a standard model of a Boeing aircraft (777, IIRC) that's used as a something of a test scene in the computer graphics community. It's about 350M triangles (everything down to nuts and bolts, but modified so as not to give any trade secrets away) and over 4GB of data, so it gets used a lot for testing how the performance of an algorithm scales to large datasets.
Aye! I was thinking the same thing, though I'd put OCaml (or SML, if that's your flavor) up there as well.
I've come to believe that Perlis had it write when he said: "A language that doesn't affect the way you think about programming, is not worth knowing." Getting comfortable with functional languages has definitely affected the way I program, even when I'm writing C++ code. I can look at something like a functor object and think, "oh, that's basically just an explicit closure." It's been very enlightening, especially since it seems like many of the idioms from the functional world have started creeping into the mainstream lately. To me, I find it much like adding a new set of design patterns to the toolbox -- it gives you a handle on the concepts and a vocabulary to refer to the ideas by even if you don't code in a functional language.
Yes, but what has he sworn under affidavit? That he built a prototype? That he built a prototype, and the guy who asked him to intended to use it? Or that he built a prototype and it was used in the election?
From the affidavit (bolding theirs):
She immediately stated, "
You don't understand, in order to get the contract we have to hide the manipulation in the source code. This program is needed to control the vote in South Florida." I was shocked that they were actually trying to steal the election and told her that neither I nor anyone else could produce such a program. She stated that she would hand in what I had produced to Feeney and left the room with the software.
Of course, why you'd tell someone what you intend to do is beyond me. No one seems to come off very classy in this business. You'd also figure that if they were that free with their information, surely there'd be more people around to corroborate this guys story if it's true.
The affidavit mentions meeting Feeney in early fall of 2000 and being asked to develop the prototype then.
Still, I agree, something doesn't smell right. He makes quite a few allegations in that affidavit, which makes me wonder why the hell he didn't get out of Dodge sooner. I'd definitely like to have more facts before taking a guess at what really happened.
Of course, I live in Chicago, so I'm cynical and pessimistic and just laugh whenever either of the two major parties tries to take the moral high ground regarding voting irregularities.
1) I won't argue ideology here; I'm from the pragmatic use-what-works school. But I have Joel Spolsky's Fire and Motion column in mind here. Once the runtime technology reaches maturity, there's not really any need for Mono to try to keep up. Look at Java: how many of the extra libraries are really used? Most programmers won't have a need for too much beyond the core library and won't bother learning all the silly esoteric additions. Once Mono's caught up with the (fairly static) core and can run 99% of the programs out there, it'll probably be good enough for most people.
2) Functional programming is all about creating abstractions. Yes, depending on the language's FFI the abstraction layer might look ugly. But I'll bet it's still faster to create a small functional-style shim layer on top of a set of FFI calls than it is to reimplement the routines from scratch. You can always migrate to more elegant pure code later if you really want to spend the time on it.
3) Programmer time is expensive, hardware time is cheap. By your argument we'd all be writing assembly code and no one would ever use a scripting language. Most people using a high level functional language aren't doing it for performance reasons; they're doing it for the higher levels of abstraction they can achieve. I think many would gladly trade the performance penalty you mention for a chance to save themselves the chore of all that extra coding and debugging.
One solution that many of these languages are now taking is to target either the.NET framework or the JVM. For example, F# and SML.NET are two different projects from Microsoft Research aimed at producing ML-like compilers targeted at.NET. The Bigloo Scheme compiler now has an experimental.NET backend in addition to native code and JVM backends. There are also some Haskell compilers targetting the.NET now. If you look around, quite a few functional languages are beginning to support some combination of.NET and the JVM.
For many languages, this solves exactly the problem that you describe. The new language instantly gets the benefit of large, useful and well tested library. The language developers can focus on the design of their language and leave the hassle of building and maintaining the supporting run-time and library to someone else. Eventually they can add a more native-feeling system library layer over it, but targeting the.NET or JVM gets them off the ground right away.
There's a few quirks involved in shoehorning functional languages this way. As I recall, the JVM is a bit more difficult to compile functional languages to since it is really intended to run Java..NET is a bit easier, though there are still some quirks. Many of those are known at this point, however, and there are even some libraries even to help work around them (e.g. the ILX SDK developed for F#.) I also think I recall something about the next update to MSIL addressing many of those quirks to simplify the development of functional language compilers.
My father is professor at a med school. One of the things I've often heard from the profs is about both the sheer volume of material that must be imparted to the students. One thing they tell me is that, compared to an upper level undergraduate course a med school course normally has triple to quadruple the amount of information to learn on top of which the students are required to learn it even better. I've been told about how even some students are at or near the top of their class in undergraduate studies are unable to cope. And it's not the profs in med school *want* to be mean or excessive, it's just the nature of the profession that requires it. No one wants to place their lives in the hands of a doctor who doesn't know their stuff.
Most med school classes are already large as it is; better to keep the entrance requirements high than waste time on people who aren't going to survive it anyway. Basically what I'm saying is that, from what I've heard, though the entrance requirements are tough, med-school itself is even tougher.
Regarding doctors being in short supply and expensive, I'd lay the blame on the insane medical malpractice insurance fees that are now a requirement of working in the field. Look at the situation in West Virginia for example. Doctors refuse to work there for fear of being sued into oblivion.
I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.
OCaml annoys me slightly because it seems so tantalizingly close to what I'm looking for but falls just short. For one, I wish it had better support for generative programing. Sure, for template like stuff you can immitate that to some extent through the polymorphism, but because it has to be generic, it still doesn't work out performance-wise. Look at the kind of stuff they can do with Blitz++. And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!) The model that I really like is the macro systems in Lisp or Scheme. That would require a Lisp-like syntax to work, but I'm cool with that.
The other thing that bugs me a bit is that the compiler seems fairly simple in regards to optimization passes. When I've looked at assembly output from it, even with all optimizations turned on, I was surprised to see that it doesn't seem to do common subexpression elimination or strength reduction, like a common C compiler could do for you. I realize that OCaml is more functional, which constrains the compiler a bit, but there are compilers for other functional languages that manage to do flow graph analysis and optimization. (e.g. Stalin for Scheme) This lack is dissapointing in a higher level, more declarative style language like OCaml.
Finally, one other thing is that while the foreign-function interface to C is better than many other functional languages, I wish it were still better. With OCaml, it seems like you'd still need a small library in C as a shim to interface between the two languages. It would be nice if you could simply declare a function's signature, mark it as an external C function and link the library in. To deal with garbage collection, I'd borrow something like the "pin" construction from C#. I think C# and the.Net framework have a really nice model for FFI.
Of course, if you don't need such heavy duty performance, OCaml's still a great system and a fair sight better than many other functional language systems. But it's not a panacea for everything.
One more thing: if you use (X)Emacs, be sure to have a look at Tuareg Mode.
No, but it is not this simple. Pointer comparison in C does not have to fit the rules of numerical equality. The way you state it, it's as if the compiler converts the pointers to integers and then compares them.
Agreed. I may be showing my age with this example, (heh) but I still remember programming the x86 in the bad old days of 640k and the segmented memory architecture. Modern OS's and processors give us the facade of a nice flat, linear logical address space, from here to 4 billion. But back then, while pointers were typically 32-bit values, there were only 20-bits of addressable memory space; twelve of those bits in the pointers were redundant. The upper 16 bits would hold the segment, and the lower 16 bits would hold the offset.
So if you wanted to properly compare two pointers, you'd have to split each pointer into a pair of 16 bit words (the segment and offset), right-shift the high word 4 bits and add that to the low word. Only then would you have a number that you could compare and get accurate results.
If you simply tried to just treat them as two integers and compare them that way, you'd run the risk of finding them unequal, even though they're really aliases for the same memory location. e.g. A000:0010 == A001:0000, but you wouldn't know that if you just compared them as two 32-bit ints.
Bah! Enough of this esoterica. Suffice to say pointers are not ints and your code is non-portable if you treat them as such.
I just placed the order for my x30 on Wednesday after a similiar analysis.
I'd wanted to get a PDA again and decided to hold off until the new batch was announced. I wanted to see what Palm would offer. When I saw the specs for the T5, I was distinctly underwhelmed.
I too had been hoping that it would ship with Cobalt, since that sounded fairly interesting. I'd also expected Wi-fi and a greater memory increase. Instead we got a new machine that's barely different than the old one except a substantial increase in price. So it can (finally) be used as portable storage like a USB key. Big deal -- I can get a USB key with more memory for an eighth of the price. Another factor for me is the battery. I've resigned myself to the fact that these things eat battery power pretty quickly. Fine. But if that's the case, I want to be able to swap in a fresh spare when the current battery gets low. The dang thing's a portable device -- I'm not always going to be near a charger when the battery starts to give out! A sealed battery in a device that runs it down that quickly is just insane.
When I compared the T5 to the x30, there was simply no question. The x30 gives me both Bluetooth *and* Wi-fi, a working SDIO slot, a faster processor, a newer OS, the ability to swap batteries, etc. And for all of its faults, the T5 seems to share them. What really made the deal for me though, was that if you get the x30 when it's 15% off, it's a hundred dollars cheaper than the T5. When I specced it out, I found that I could get the x30 plus either an spare extended 1800 mAH battery or a 1 GB SD card and still come out ahead of the T5 on price.
The answer is simple. Those are weasel words. It probably means they looked at the data on their customers and decided to change the rules to squeeze them a little more.
Agreed. A good animator is still needed to clean up the mocap data; smoothing it out and deleting spurious data.
The other problem that I have with exclusively using mocap is that without help from an animator, it fails to take into account the discrepencies in mass. By that I mean that size, weight, build, etc. all influence the range of positions and speed of motions that look natural. Mapping the movements of a skinny actor onto a huge ogre is going to look pretty odd, for example. Sure, the actor could slow down and exagerate his movements but you'll still want an animator to make the mapping look good. Besides, ever see an actor trying to pick up a light weight prop and but make it look heavy? It never works; physiologically you just can't control all those reflexive muscle tensings and it never looks good -- the prop usually seems to just lift off the ground a little too easily while the actor tenses himself a moment too late or too soon. And I'm not saying it isn't hard for animators either -- creating the illusion of mass with CG is one of the hardest things to do. But at least a good animator will know the tricks for that and be able to help.
I know others have mentioned it in this thread, but do have a look at OCRemix.org and VGMix.com. Both have some very nice remixes of FF music. (OCRemix even has a remix of the FF6 theme in homage to Uematsu from Jeremy Soule, composer for quite a few recent games.) Finally, for the original stuff, I'd suggest having a look at Zophar's Domain. One of the reasons I still use WinAmp and not iTunes or such is for the SNESAmp plugin to play the SNES SPC files.
If you haven't seen it, you might find Google Personalized Search interesting. The interface is fairly slick and lets you set preferences to tweak the weights on your searches. Unfortunately, there's no login but it's just a cookie which is easy enough to carry around if you have to.
Bah! A real geek would have done it with an HP-48 calculator./fond memories.
Dang. Misread the headline.
on
Halo 2 Goes Gold
·
· Score: 2, Funny
There for a moment, I'd read the headline as Half-life 2 goes gold, got excited, and then wondered what Bungie or Microsoft had to do with it. Oh well.
Sure. I simply find the endless name calling contemptibly irritating regardless of political affiliation. I didn't like the Clinton name calling any better. It just so happens that with the Bush administration in power, he is the target these days. Were Kerry in power and his opposition engaging in the same sort of name calling I'd find it just as contemptible.
Political debate is a fine thing, but I just happen to feel that it should be done on the merits of the ideas rather than some unfortunate coincidence in the pattern of letters in a persons name. Leave the name calling to the school yard is all I ask. It just looks petty and doesn't win anyone to your side.
As for humour, I've read perfectly fine, creative, witty humour from both sides, but this sort of thing isn't it. This is invective. It's trite and dull and doesn't get any better with the 10,000th repetition. Hearing it again isn't change anyone's opinion. Good humour is topical and unique.
Slashdot Mirror
Try http://graphics.cs.uni-sb.de/MassiveRT/boeing777.h tml when they're no longer being slashdoted.
I can't speak for the chip yet, but I've read the papers on their software system and know that it gets a good part of its speed by rendering triangles only. The secret is that they have a cleverly laid-out, cache-friendly BSP tree of the triangles and their code uses MMX SIMD instruction to intersect 4 rays at a time with the triangles in the tree. Rendering triangles only lets them get away with a more compact (and therefore more cache friendly) memory structure and lets them avoid the performance penalty of switching or [vtable] dispatching on object types -- it's all one very tight loop to walk the tree and intersect triangles.
How about non-tesselated geometry? You can have high detail curved surfaces without turning everything into a dense polygon mesh. That in turn lowers the memory and rendering requirements so you can apply those resources to proper detail instead.
Or how about global illumination lighting effects? Truely emissive surfaces and area lights? As a hobbyist map maker, I would kill to have an engine that supported these; imagine being able to just tag the sky as an emmisive surface and have the entire level lit up and shadowed accordingly without having to painstakingly add bounce lights everywhere and tune them till they looked correct.
Another good argument that I've heard is based on the complexity of the algorithms. GPU style rendering is inherently order O(n) on the number of items in the scene. While ray-tracing has a high constant factor, a good ray tracing acceleration structure makes the problem O(log n) -- as the scene grows the time to ray trace gets closer to the time to GPU render it. Admittely you can do much the same with the GPU: there's a lot of stuff like BSP trees and bounding volume heirarchies and frustrum culling that you can do to speed it up, but then you're already applying ray-tracing techniques anyway, and now you're really talking about something that's more of a hybrid with the CPU just doing the ray-tracing part.
There's a standard model of a Boeing aircraft (777, IIRC) that's used as a something of a test scene in the computer graphics community. It's about 350M triangles (everything down to nuts and bolts, but modified so as not to give any trade secrets away) and over 4GB of data, so it gets used a lot for testing how the performance of an algorithm scales to large datasets.
I find MiKTeX works wonderfully for me on Windows. Between that and Windows ports of GNUPlot, Ghostscript, and XEmacs, I can be quite productive.
Aye! I was thinking the same thing, though I'd put OCaml (or SML, if that's your flavor) up there as well.
I've come to believe that Perlis had it write when he said: "A language that doesn't affect the way you think about programming, is not worth knowing." Getting comfortable with functional languages has definitely affected the way I program, even when I'm writing C++ code. I can look at something like a functor object and think, "oh, that's basically just an explicit closure." It's been very enlightening, especially since it seems like many of the idioms from the functional world have started creeping into the mainstream lately. To me, I find it much like adding a new set of design patterns to the toolbox -- it gives you a handle on the concepts and a vocabulary to refer to the ideas by even if you don't code in a functional language.
From the affidavit (bolding theirs): Of course, why you'd tell someone what you intend to do is beyond me. No one seems to come off very classy in this business. You'd also figure that if they were that free with their information, surely there'd be more people around to corroborate this guys story if it's true.
The affidavit mentions meeting Feeney in early fall of 2000 and being asked to develop the prototype then.
Still, I agree, something doesn't smell right. He makes quite a few allegations in that affidavit, which makes me wonder why the hell he didn't get out of Dodge sooner. I'd definitely like to have more facts before taking a guess at what really happened.
Of course, I live in Chicago, so I'm cynical and pessimistic and just laugh whenever either of the two major parties tries to take the moral high ground regarding voting irregularities.
I've been using Bigloo (from the same folks as OCaml) for Scheme. You might find it gives you a lot of what you want.
1) I won't argue ideology here; I'm from the pragmatic use-what-works school. But I have Joel Spolsky's Fire and Motion column in mind here. Once the runtime technology reaches maturity, there's not really any need for Mono to try to keep up. Look at Java: how many of the extra libraries are really used? Most programmers won't have a need for too much beyond the core library and won't bother learning all the silly esoteric additions. Once Mono's caught up with the (fairly static) core and can run 99% of the programs out there, it'll probably be good enough for most people.
2) Functional programming is all about creating abstractions. Yes, depending on the language's FFI the abstraction layer might look ugly. But I'll bet it's still faster to create a small functional-style shim layer on top of a set of FFI calls than it is to reimplement the routines from scratch. You can always migrate to more elegant pure code later if you really want to spend the time on it.
3) Programmer time is expensive, hardware time is cheap. By your argument we'd all be writing assembly code and no one would ever use a scripting language. Most people using a high level functional language aren't doing it for performance reasons; they're doing it for the higher levels of abstraction they can achieve. I think many would gladly trade the performance penalty you mention for a chance to save themselves the chore of all that extra coding and debugging.
One solution that many of these languages are now taking is to target either the .NET framework or the JVM. For example, F# and SML.NET are two different projects from Microsoft Research aimed at producing ML-like compilers targeted at .NET. The Bigloo Scheme compiler now has an experimental .NET backend in addition to native code and JVM backends. There are also some Haskell compilers targetting the .NET now. If you look around, quite a few functional languages are beginning to support some combination of .NET and the JVM.
.NET or JVM gets them off the ground right away.
.NET is a bit easier, though there are still some quirks. Many of those are known at this point, however, and there are even some libraries even to help work around them (e.g. the ILX SDK developed for F#.) I also think I recall something about the next update to MSIL addressing many of those quirks to simplify the development of functional language compilers.
For many languages, this solves exactly the problem that you describe. The new language instantly gets the benefit of large, useful and well tested library. The language developers can focus on the design of their language and leave the hassle of building and maintaining the supporting run-time and library to someone else. Eventually they can add a more native-feeling system library layer over it, but targeting the
There's a few quirks involved in shoehorning functional languages this way. As I recall, the JVM is a bit more difficult to compile functional languages to since it is really intended to run Java.
Yeah, you know it's bad when (X)Emacs starts up several times more quickly!
My father is professor at a med school. One of the things I've often heard from the profs is about both the sheer volume of material that must be imparted to the students. One thing they tell me is that, compared to an upper level undergraduate course a med school course normally has triple to quadruple the amount of information to learn on top of which the students are required to learn it even better. I've been told about how even some students are at or near the top of their class in undergraduate studies are unable to cope. And it's not the profs in med school *want* to be mean or excessive, it's just the nature of the profession that requires it. No one wants to place their lives in the hands of a doctor who doesn't know their stuff.
Most med school classes are already large as it is; better to keep the entrance requirements high than waste time on people who aren't going to survive it anyway. Basically what I'm saying is that, from what I've heard, though the entrance requirements are tough, med-school itself is even tougher.
Regarding doctors being in short supply and expensive, I'd lay the blame on the insane medical malpractice insurance fees that are now a requirement of working in the field. Look at the situation in West Virginia for example. Doctors refuse to work there for fear of being sued into oblivion.
I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.
.Net framework have a really nice model for FFI.
OCaml annoys me slightly because it seems so tantalizingly close to what I'm looking for but falls just short. For one, I wish it had better support for generative programing. Sure, for template like stuff you can immitate that to some extent through the polymorphism, but because it has to be generic, it still doesn't work out performance-wise. Look at the kind of stuff they can do with Blitz++. And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!) The model that I really like is the macro systems in Lisp or Scheme. That would require a Lisp-like syntax to work, but I'm cool with that.
The other thing that bugs me a bit is that the compiler seems fairly simple in regards to optimization passes. When I've looked at assembly output from it, even with all optimizations turned on, I was surprised to see that it doesn't seem to do common subexpression elimination or strength reduction, like a common C compiler could do for you. I realize that OCaml is more functional, which constrains the compiler a bit, but there are compilers for other functional languages that manage to do flow graph analysis and optimization. (e.g. Stalin for Scheme) This lack is dissapointing in a higher level, more declarative style language like OCaml.
Finally, one other thing is that while the foreign-function interface to C is better than many other functional languages, I wish it were still better. With OCaml, it seems like you'd still need a small library in C as a shim to interface between the two languages. It would be nice if you could simply declare a function's signature, mark it as an external C function and link the library in. To deal with garbage collection, I'd borrow something like the "pin" construction from C#. I think C# and the
Of course, if you don't need such heavy duty performance, OCaml's still a great system and a fair sight better than many other functional language systems. But it's not a panacea for everything.
One more thing: if you use (X)Emacs, be sure to have a look at Tuareg Mode.
No, but it is not this simple. Pointer comparison in C does not have to fit the rules of numerical equality. The way you state it, it's as if the compiler converts the pointers to integers and then compares them.
Agreed. I may be showing my age with this example, (heh) but I still remember programming the x86 in the bad old days of 640k and the segmented memory architecture. Modern OS's and processors give us the facade of a nice flat, linear logical address space, from here to 4 billion. But back then, while pointers were typically 32-bit values, there were only 20-bits of addressable memory space; twelve of those bits in the pointers were redundant. The upper 16 bits would hold the segment, and the lower 16 bits would hold the offset.
So if you wanted to properly compare two pointers, you'd have to split each pointer into a pair of 16 bit words (the segment and offset), right-shift the high word 4 bits and add that to the low word. Only then would you have a number that you could compare and get accurate results.
If you simply tried to just treat them as two integers and compare them that way, you'd run the risk of finding them unequal, even though they're really aliases for the same memory location. e.g. A000:0010 == A001:0000, but you wouldn't know that if you just compared them as two 32-bit ints.
Bah! Enough of this esoterica. Suffice to say pointers are not ints and your code is non-portable if you treat them as such.
I just placed the order for my x30 on Wednesday after a similiar analysis.
I'd wanted to get a PDA again and decided to hold off until the new batch was announced. I wanted to see what Palm would offer. When I saw the specs for the T5, I was distinctly underwhelmed.
I too had been hoping that it would ship with Cobalt, since that sounded fairly interesting. I'd also expected Wi-fi and a greater memory increase. Instead we got a new machine that's barely different than the old one except a substantial increase in price. So it can (finally) be used as portable storage like a USB key. Big deal -- I can get a USB key with more memory for an eighth of the price. Another factor for me is the battery. I've resigned myself to the fact that these things eat battery power pretty quickly. Fine. But if that's the case, I want to be able to swap in a fresh spare when the current battery gets low. The dang thing's a portable device -- I'm not always going to be near a charger when the battery starts to give out! A sealed battery in a device that runs it down that quickly is just insane.
When I compared the T5 to the x30, there was simply no question. The x30 gives me both Bluetooth *and* Wi-fi, a working SDIO slot, a faster processor, a newer OS, the ability to swap batteries, etc. And for all of its faults, the T5 seems to share them. What really made the deal for me though, was that if you get the x30 when it's 15% off, it's a hundred dollars cheaper than the T5. When I specced it out, I found that I could get the x30 plus either an spare extended 1800 mAH battery or a 1 GB SD card and still come out ahead of the T5 on price.
Sorry, Palm. You blew it this round.
The answer is simple. Those are weasel words. It probably means they looked at the data on their customers and decided to change the rules to squeeze them a little more.
Agreed. A good animator is still needed to clean up the mocap data; smoothing it out and deleting spurious data.
The other problem that I have with exclusively using mocap is that without help from an animator, it fails to take into account the discrepencies in mass. By that I mean that size, weight, build, etc. all influence the range of positions and speed of motions that look natural. Mapping the movements of a skinny actor onto a huge ogre is going to look pretty odd, for example. Sure, the actor could slow down and exagerate his movements but you'll still want an animator to make the mapping look good. Besides, ever see an actor trying to pick up a light weight prop and but make it look heavy? It never works; physiologically you just can't control all those reflexive muscle tensings and it never looks good -- the prop usually seems to just lift off the ground a little too easily while the actor tenses himself a moment too late or too soon. And I'm not saying it isn't hard for animators either -- creating the illusion of mass with CG is one of the hardest things to do. But at least a good animator will know the tricks for that and be able to help.
RTFA: He addresses this off the bat. That's part of why he claims they have so much power.
I know others have mentioned it in this thread, but do have a look at OCRemix.org and VGMix.com. Both have some very nice remixes of FF music. (OCRemix even has a remix of the FF6 theme in homage to Uematsu from Jeremy Soule, composer for quite a few recent games.) Finally, for the original stuff, I'd suggest having a look at Zophar's Domain. One of the reasons I still use WinAmp and not iTunes or such is for the SNESAmp plugin to play the SNES SPC files.
If you haven't seen it, you might find Google Personalized Search interesting. The interface is fairly slick and lets you set preferences to tweak the weights on your searches. Unfortunately, there's no login but it's just a cookie which is easy enough to carry around if you have to.
I mean, yeah, it can't even do e-mail yet. er... wait...!
Bah! A real geek would have done it with an HP-48 calculator. /fond memories.
There for a moment, I'd read the headline as Half-life 2 goes gold, got excited, and then wondered what Bungie or Microsoft had to do with it. Oh well.
/Still waiting for Duke Nukem...
Sure. I simply find the endless name calling contemptibly irritating regardless of political affiliation. I didn't like the Clinton name calling any better. It just so happens that with the Bush administration in power, he is the target these days. Were Kerry in power and his opposition engaging in the same sort of name calling I'd find it just as contemptible.
Political debate is a fine thing, but I just happen to feel that it should be done on the merits of the ideas rather than some unfortunate coincidence in the pattern of letters in a persons name. Leave the name calling to the school yard is all I ask. It just looks petty and doesn't win anyone to your side.
As for humour, I've read perfectly fine, creative, witty humour from both sides, but this sort of thing isn't it. This is invective. It's trite and dull and doesn't get any better with the 10,000th repetition. Hearing it again isn't change anyone's opinion. Good humour is topical and unique.