The narrowest of niche sciences still progresses too fast in too many directions for even specialists to keep up in a meaningful way. Half of scientific inquiry is putting decimals on the end of constants nobody can bring themselves to care about, and half of it is The Singularity In Action. Humankind doesn't operate at the speed of cutting-edge science at this point, and asking a journalist to do anything other than offer pointers to the fun milestones is like trying to find the edge of the universe - the "edge" Doesn't Really Exist, it's moving away from you faster than you could ever hope to travel, and if in some tricksy way you manage to catch up you'll find that everything has changed.
Maybe the mass thief is lowering the reference weight by a small amount? Or just putting a heavy object vaguely "underneath".
Gravity is a gradient field, after all.
CoH tried the no-classes thing. It lead to a lot of gimped characters making it through the creation process. In a commercial product, that's not acceptable.
Note that of the classes named, only the Rogue, Warrior, and Hunter actually stand out to any degree. Warriors seem to be doing ok again, so scratch one issue. Rogues aren't easy to get into instances, so scratch two. And with the introduction of BG, I've seen a lot of hunter 3.
This type of testing, to be done properly, requires tool support, and it isn't properly done at a unit test level. A unit test tests the bare facts, like "Are you issuing the select or sproc as desired?" When you need this level of testing, as has been mentioned, mocks will suffice. When you need to see that the code is functioning alongside the database itself (more commonly called "systems" or "integration" testing), you should have a tool on hand that can re-create a particular configuration based on a pre-populated database (which can originally be done by a proper QA resource/functional expert).
ld
Next 10 years, bottom line is that the bottom drops out of the upward climb of home electronics. With a stable target to develop against, closed-source game engines have very few places go. At this point, we already have a dozen good OSS engines ready for use, but they're subsystem engines. Given a decade, however, it's likely that the community will have at least a few decent Facades over top to provide the world with good, solid cameras with which to shoot interactive entertainment.
Assets like art and story, on the other hand, are copyrighted works and are only susceptible to market pressures. Very few people out there shooting mass-distribution movies for free either. Doesn't seem to be boiling anyone's mind that this is the case, tho.
I'm definitely not feeling the graphics. The content they're loading is old and sad, and the terrain engine isn't using any of the techniques that really make terrain look sweet.
Has anyone taken a look at upcoming RTS games such as Dawn of War, or even just terrain engine demos, to see where the graphics are going? Props to the team, but in all seriousness the graphic engine isn't anything to lose your mind over.
a) You still have to test on all platforms (a new version of the JVM counts as a platform, btw) because you can almost never rely on proper and performant support for all features
b) so yeah, I'd choose my deployment targets and compile the binaries I think are going to end up mattering the most.
When you compile a C program for an x86 platform, you compile to the lowest common denominator. Your compiler cannot assume the presence of advanced instruction sets, like MMX or SSE2. It must restrict itself to outputting code that will run on a 386.
Apparently, somebody's been keeping up with the basics of the command-line compilers but not the nice GUIs that let us easily manage & optimize for specific build targets.
The narrowest of niche sciences still progresses too fast in too many directions for even specialists to keep up in a meaningful way. Half of scientific inquiry is putting decimals on the end of constants nobody can bring themselves to care about, and half of it is The Singularity In Action. Humankind doesn't operate at the speed of cutting-edge science at this point, and asking a journalist to do anything other than offer pointers to the fun milestones is like trying to find the edge of the universe - the "edge" Doesn't Really Exist, it's moving away from you faster than you could ever hope to travel, and if in some tricksy way you manage to catch up you'll find that everything has changed.
Maybe the mass thief is lowering the reference weight by a small amount? Or just putting a heavy object vaguely "underneath". Gravity is a gradient field, after all.
p2pnet: FAIR(ly hotheaded) and BALANCED (precariously between mouthpiece and rabid lobbyist)
Drive in snow much?
CoH tried the no-classes thing. It lead to a lot of gimped characters making it through the creation process. In a commercial product, that's not acceptable.
Agreed
http://www.gankcentral.com/classcompare.aspx
Note that of the classes named, only the Rogue, Warrior, and Hunter actually stand out to any degree. Warriors seem to be doing ok again, so scratch one issue. Rogues aren't easy to get into instances, so scratch two. And with the introduction of BG, I've seen a lot of hunter 3.
Better yet, simply use a good name for the function and parameters ComputeRMSOfSignal(double signalComponents[]) ld
This type of testing, to be done properly, requires tool support, and it isn't properly done at a unit test level. A unit test tests the bare facts, like "Are you issuing the select or sproc as desired?" When you need this level of testing, as has been mentioned, mocks will suffice. When you need to see that the code is functioning alongside the database itself (more commonly called "systems" or "integration" testing), you should have a tool on hand that can re-create a particular configuration based on a pre-populated database (which can originally be done by a proper QA resource/functional expert). ld
Next 10 years, bottom line is that the bottom drops out of the upward climb of home electronics. With a stable target to develop against, closed-source game engines have very few places go. At this point, we already have a dozen good OSS engines ready for use, but they're subsystem engines. Given a decade, however, it's likely that the community will have at least a few decent Facades over top to provide the world with good, solid cameras with which to shoot interactive entertainment.
Assets like art and story, on the other hand, are copyrighted works and are only susceptible to market pressures. Very few people out there shooting mass-distribution movies for free either. Doesn't seem to be boiling anyone's mind that this is the case, tho.
Ummm...he's reported in the BBC article to be using optical telescopes. Are they simply wrong, or has he switched teams, so to speak?
I'm definitely not feeling the graphics. The content they're loading is old and sad, and the terrain engine isn't using any of the techniques that really make terrain look sweet.
Has anyone taken a look at upcoming RTS games such as Dawn of War, or even just terrain engine demos, to see where the graphics are going? Props to the team, but in all seriousness the graphic engine isn't anything to lose your mind over.
UnixWare treats a Hyperthreaded processor as a single processor, an advantage for applications with multi-processor licensing
It's probably been done by other systems too, but it still speaks to an emergent solution to a problem that's growing more important every da
I'm thinking the best prize would be the $100,000 to $1,000,00 a head, but I could be smoking the pipe here. ld
Books have the same problem. As do movies. As do vacuum cleaners. As do (new) cars. Life sucks, get over it.
ld
a) You still have to test on all platforms (a new version of the JVM counts as a platform, btw) because you can almost never rely on proper and performant support for all features
b) so yeah, I'd choose my deployment targets and compile the binaries I think are going to end up mattering the most.
Not when he did, however. His forces were ill-prepared, a mistake repeated a century later by German forces.