They haven't gone far enough! I'm looking forward to when my government stops asking me very personal and intrusive questions about who I work for and how much money I earn. From a freedom point of view this is exactly the right thing to do, too.
</kook>
The abolition of the long form census (and it was abolished-- the National Household Survey takes it place, but is no substitute) is wonderfully meta. It robs us of a valuable tool for sound, evidence-based decision making, and it was done by a government hell-bent on avoiding making a sound, evidence-based decision when world+dog showed them how awful an idea it was.
You can talk about what kind of crackmonkey 19th century scheme it is to have a subscription fire service in the first place, but that's another discussion.
If you have a subscription fire service and you want it to survive you have to protect it from freeloaders. One saved house here will mean a whole lot of lost subscriptions from people who realize you don't have to pay to get your home saved. Then, the service collapses and what do you say when a responsible former subscriber's place goes up in flames as a result?
It's not like these services just let you forget to pay, either. They do everything they can to make sure you know what it means if you haven't and don't pony up your equivalent-of-a-cup-of-coffee-a-week.
That was funny in a sense, but also very very sad. There is a growing population that would have a very hard time using a pen and paper. I know you were joking, but I see this as a problem. The more one grows to rely (as opposed to just using) technology the more one is incapable of taking care of oneself when deprived of said technology.
Translation: Get off my lawn.
I'm all for tech obviously or I wouldn't be in IT and wouldn't post here, but your 'joke' just underlines how weak and soft people are growing as they increasingly rely on tech that could go away in a heartbeat.
Translation: Those dratted kids.
One big EMP and there would be a bunch of geeks milling around not quite knowing what to do as they slowly starve to death staring at their smartphones waiting for them to turn back on.
Translation: I've fallen, and I can't get up.
Let's bear in mind, please, that geeks will have no monopoly on starvation and privation if someone starts lobbing EMPs around. There will be bigger problems than kids' unfamiliarity with pen and paper if the pillars of our society are tumbling down around our ears. If your bunker isn't fully stocked and you aren't practicing subsistence agriculture right now, then your post is the height of hypocrisy.
Well, first you have to get a system in place. So you get to pay $BIGNUM for something you need to hack anyway.
(As a side note... unless your post is tongue in cheek... does it constitute a breach of DMCA or similar? Should we be horrified that each system has the same root password as you're implying?)
Of course, if you just generate a patch file with the source changes, and zip that up, it will be even tinier.
Except for that upgrade of the underlying FooLib from 2.1 to 2.2 that's part of your hotfix. Well, all you need then is to just get a patch file for that too, and include that.
And then compile the whole sucker on the other end.
Everyone's got plenty of CPU, right? And we're just about all using trivially decompilable bytecode anyway, so if you make your patchfile based on the source changes after compilation and decompilation, you've got all the right transforms in place to come up with a pretty effectively minimal changeset.
Of course, we have plenty of bandwidth anyway, and programs are small. Media files are not, but I'm not going to get any space savings trying to disassemble that picture of your mom.
I used to have a daily (static) stretch routine that has lapsed since I hung up my skates, so I'm looking at this article with interest and trying to match them against my own observations and routine:
1. The purpose of the stretching routine was to allow the muscles to lengthen and reduce the chance of injury that wild flailing contortions on a slippery surface exposes you to.
TFA suggests that muscles are "weakened" (in terms of performance) but does not say that those muscles have been exposed to injury risk. Also, the parts of my body I'm protecting are the non-stretchy bits of ligament and tendon that may see too much load if muscles are too tight.
2. The routine was a set of systematic, static stretches held for a minimum of 30 seconds. But the whole set was always, always, always preceded by a light warmup: jogging, a few pushups, etc.
This is borne out by the article, which said (surprise!) that warmed up muscles work better. In fact, cold muscles are just hard to stretch, and you risk injuring yourself right there.
Dynamic stretching was something I was aware of at the time, but it came with a bit of a warning-- if you don't know what you're doing with exercises that stretch muscles that are under tension, or you're not in peak physical shape, you can hurt yourself pretty fast.
It does sound like there's been progress in this area... it was very hard to find information on "how to do effective dynamic stretching without breaking yourself" five years ago.
Now... as for the "ex" part of "ex-goalie": my first knee injury was an MCL tear on a game in early summer, when I wasn't in a regular stretch routine, when I hadn't followed my regimen properly before game. That emphasizes to me that not following a stretching routine was infinitely worse than a static stretching routine. I won't comment on whether what I did do was optimal-- I suspect it could have been improved.
(FWIW it wouldn't have saved me from knee injuries #2 and #3, patella subluxations that put me out of the sport for good. Turns out I have shallow trochlear grooves and sliding kneecaps are bad if you like butterfly goaltending and dislike obscene amounts of pain.)
So best I can say is that this article's pretty inconclusive about whether static stretching is actually bad. I believe that even if it cuts your muscle output, it's still having an effect in increasing your safe range of motion, and both (a) better than no stretching and (b) more easily managed for an amateur than some potentially aggressive dynamic stretching approaches.
The laundry list of limitations in Qt3 driving the move have long since faded from my memory (though I seem to recall Vista support being a fairly large motivator.) But apart from that, ongoing commercial development requires active support, and Trolltech's support services have long since dropped support for Qt3.
Porting from Qt2 to 3 was a breeze, compared to the move to Qt4. The automated porting tools didn't do much for us, and the Q3Support layer-- while it gave us a good stepping stone-- eventually had to be ripped out almost entirely because we kept hitting all sorts of esoteric bugs that couldn't be solved without porting the code all the way.
To be fair... I like Qt a lot, and it's still my first choice for multiplatform GUI development. (Before many of the platforms sank into obscurity our app suite built from a common C++/STL/Qt codebase onto Windows, Linux, Solaris, HPUX, AIX, Irix and OSF, which still impresses the crap out of me.:) )
Re:oh goody.
on
C# In-Depth
·
· Score: 5, Interesting
Having spent the last seven years using Qt and C++, and the last two comparing that with C#, I'd agree with the original poster: C# is a better choice for fast productivity to a GUI.exe for Windows.
Throw other platforms into the mix and my decision changes, but that's not what he stated, is it?
Qt lost a lot of points in my book for just how much time was destroyed in porting our code to Qt4. Two years later, and we're still asking for bugfixes.
Nokia doesn't make their money licensing software, and I don't think they want to change that now.
This is the part I disagree with. TT's commercial market may not have been "lucrative", but it was enough to keep the company afloat and growing for the last decade or so. Niche revenue is still revenue and I would be surprised if Nokia decided to simply write it off.
But I do see the upside to Nokia offering a free (beer) license for "its" mobile platform SDK. Less so for a free (speech) license. I don't think they'll discount the existing revenue stream quite so quickly though.
I'm looking more closely at the future of Qt on the desktop. I've been working as a developer at a company that provides a not-insignificant portion of TT's revenue in licensing fees, since the Qt2 days-- and after the pain and suffering of the port to Qt4, this is another bit of disquieting news. I'm not sure TT's new imperial overlords are as interested in the desktop toolkit as the mobile product.
But then, I can only hope they won't be so quick to throw away that revenue stream, either, and keep responding to our bug reports.
It's really awful to have to write a very diplomatically phrased email to a team leader to explain that one of his coders has created an API in which they have consistently and unfailingly used the word "Recieve", and that some day that API will probably be part of what we expose externally, and that you'd really appreciate it being fixed before people actually start using it. But it's even worse when the API is specced in a Word doc and the misspeelings are in there, too.
Worst of all, though, is trying to use the damn API while your brain is distracting you with fits of "I before E except after C!"
None the less, the shame I felt in raising the issue at all was matched only by my disappointment that no one else had caught it already.
The babelfished translation makes a few comments about distinctions that make this sound not so bad.
Distinguishing between a 'true invention' implemented on a computer and an existing invention that just happens to be implemented on a computer for the first time is a big one. It means that Joe Q Random can't patent his chopstick indexing program just because noone's ever indexed their chopsticks with a computer before.
(Provided, of course, someone's come up with a chopstick sorting system at all... Um. Excuse me, I'll be right back...)
Two things. The first from gamasutra is a story titled "Xbox Encryption Key Under Brute-Force Hack Attack; Could Take Eons". Sounds to me like it was a noble, but ultimately futile goal.
The second is a comment I made to friends immediately after hearing the story. The Neo Project had essentially just rubbed pig's blood and feces all over itself, and then jumped into the South Pacific and splashed its arms around. Hell, they even SAID on their webpage that at the slightest hint of objection of a legal nature, they'd drop everything.
"So what you're saying," I can imagine a Microsoft landshark responding, "is that, if we tell you to stop... you will? Well, in that case.. Stop!" No doubt the landshark then submitted an expense cheque for several hours of "research".
Why did TNP even bother starting? Call me suspicious, but I think it's a big publicity stunt on TNP's part. They got attention.
We're getting an awful lot of stories hitting Ars Technica and then showing up on Slashdot days later.
I really appreciate new and interesting stuff, but if it's already made its run through other blogs, does it really need someone to pick it up from there and rehash it on/. just for cheap "I got a story posted!" thrills?
Re:Problems with WoH
on
War of Honor
·
· Score: 2, Insightful
Well, it's not as if David Weber's books are marvels for their subtle and complex characters.
In fact, if WoH is the first HH book you've noticed that the good guys are all really good and honourable and loyal and - occasionally - rapscallions, but nice fuzzy heart-of-gold rapscallions.. and the bad guys are power-hungry, greedy sons-o-thingames willing to climb a mountain of dead bodies to get to the top, or just plain namby-pamby liberal military-hating scumbags who are too stupid to understand political realities... (deep breath, deep breath).. where was I?
I'm a HH fan because the universe has a nice feel to it, Weber is a gifted author when it comes to describing space war, and of course big things happen on a grand scale. It's space opera.
His characters and dialogue really detract from it though. I've noticed between his HH series, and the Starfire books he co-authored with Steve White, a lot of the same characters appear - with different names.
The parent article is quite correct. If you're doing any solid-body physics based stuff, ODE rocks. Combine it with SDL and OSG and you have the basic tools to produce some really cool stuff. Throw in the Demeter Terrain Engine if you want a bit of scenery to go with it. I've tied all four together for experimenting with what makes a good driver interface for a hovertank.:)
The Stair-dismount makes good use of joints, and collision detection features of ODE - but even if you don't need these, the force model of ODE is a lot of fun to play with on its own. But if you *are* ambitious, it has specialised joint and suspension-spring models for doing things like wheeled vehicles pretty easily.
With all these tools available under LGPL, those of you like me - who don't like writing a graphics/physics engine so much as actually writing cool simulations with said engines - have a much better point to start from than even 2 years ago.
...Perhaps you could make a social commentary video game where you go into lower class minority neighbourhoods recruiting disenfranchised voters by blowing open their houses and picking up their pixellated arm-waving butts in your helicopter, while dodging bullets being fired at you by the Establishment's tanks, jet fighters and UFOs?
I might be wrong, I haven't dealt with that issue directly. The problem had to do with initial loading of data (we deal with as many gigabytes of 3D flow data as the OS, FS, and available resources will let us..) where a couple of very large maps get used and then discarded.
I *think* it's been alleviated by re-engineering that section such that smaller steps are used, so the high-water mark isn't as big.
You misunderstand me - we do strive for const correct programming. My point is, it's pretty difficult sometimes to sift through 6, 10, 14 lines of template name expansion just to discover that you're trying to cast a const iter to a non-const iter. At least it was at first, until you knew what it looked like.
Unless there was a specific requirement and good reason for it, I wouldn't write C++ without STL nowadays. We've been using it for the last 2+ years on about 6 different unix platforms (mostly gcc2.95 over that time) and NT (using VC6.)
In that time we' ve seen a lot of improvement as native compilers for HP, and possibly IBM are catching up and threaten to replace gcc for builds on those systems.
VC6 is a real catch.. their STL implementation is only borderline usable. The solution to this was to introduce stlport into the mix, at least for our win32 builds.
Some issues we've had: - verbose syntax (once your finger macros catch up, it's okay) - EXTREMELY verbose compile error statements - especially when using a sufficiently complex STL object (vector of strings, or something) and doing something like attempting to use a const iter in a non-const way produces monstrosities like:
passing `const string' as `this' argument of `class basic_string,__default_alloc_template > & basic_string,__default_alloc_template >::operator =(const basic_string,__default_alloc_template > &)' discards qualifiers
(and that's a simple one.)
- Bugs on various platforms, including the lovely uselessness of VC6 STL - Difficulty of examining data in debuggers - ddd+gdb gets a right ugly mess - Memory High-water-marks: Some things don't really free the memory you want them to free, just hold onto it for next time. We've discovered this when we create stupidly-large temporary maps, and then delete them. - Various little gotchas like the dangers of using remove() algorithms, being aware what map's operator[] does, etc. - Inconsistencies between std::string and the rest of the STL
But to try and be less negative: - STL has made handling data within a C++ program much more pleasant. For us, STL is fast and efficient, and has probably saved us many programmer-months in the debugging and development time required to use traditional C/C++ data structures. Plus, once you get into the mindset used by STL, it gets more and more powerful every time you read another part of the documentation.
Try playing goalie (of the hockey variety.) Not only will it suddenly become in your best interest to get in good cardio shape as well as maximize your flexibility.
It will also give you welts, bruises, and knee pain that will make you forget all about your back.:)
(Actually, I've lost some 10lb, lowered my body fat % very well, and eventually my flexibility caught up with the contortions I was doing and the knee pain stopped. All that over a single winter. Back pain? Can't remember the last time I had back pain. Actually, I can... it was when I discovered I was the world's worst horserider.)
Jamie, in the article header, you state that your analysis follows.
What follows isn't an analysis, it's preaching. What's more, it's using an issue relevant to Slashdot (age restriction of violent computer games falls in that category, I think) that's only peripherally related to something you obviously feel very strongly about, as an excuse to preach about your pet issue.
Man, I need a synonym for "preach" and quick - but you preach for several paragraphs about the cruel slaughter of animals by all us bad carnivores. Your "analysis" is nothing more than "How can this be taking place when this other thing hasn't been corrected?"
Not relevant. And a flagrant abuse as a staffer at Slashdot too.
Can someone moderate Jamie's whole 'analysis' downwards as irrelevant flamebait, please?
I was impressed by one part of the "horrifying" cinematography.
In today's age of computer graphics, some really amazing special effect lineups are possible. Everything from massive heart-pounding battle scenes to heart-renching impossible vistas. BE worked towards this, not really leading the way, but still doing a respectable job.
The one thing I was impressed by, though, at the end of the movie was their achievement tackling a problem still difficult because of its very plausableness (sp?:). It's harder to trick the human eye in areas it's intimately familiar with. Human forms and faces still aren't convincing when done straight up with CGI. So it's still a challenge.
What was it?
The size difference between the Psychlos and the humans. Not once -/not once/ - in this entire trash-heap of a movie, plot holes oozing all over the place, did I ever have a moment where I looked at the 10 foot tall beasties and the 6 foot tall oo-mans and think "this looks contrived". I realised afterwards that the one thing I was convinced about was that John Travolta really/was/ 10 feet tall (talk about being larger than life!) and looked perfectly natural in those big ol' clown shoes of his.
The director and technical staff achieved this through a pretty elegant set of means, not the least of which was very clever camera work. They achieved this one goal masterfully.
Slashdot Mirror
They haven't gone far enough! I'm looking forward to when my government stops asking me very personal and intrusive questions about who I work for and how much money I earn. From a freedom point of view this is exactly the right thing to do, too.
</kook>
The abolition of the long form census (and it was abolished-- the National Household Survey takes it place, but is no substitute) is wonderfully meta. It robs us of a valuable tool for sound, evidence-based decision making, and it was done by a government hell-bent on avoiding making a sound, evidence-based decision when world+dog showed them how awful an idea it was.
... the firefighters did exactly the right thing.
You can talk about what kind of crackmonkey 19th century scheme it is to have a subscription fire service in the first place, but that's another discussion.
If you have a subscription fire service and you want it to survive you have to protect it from freeloaders. One saved house here will mean a whole lot of lost subscriptions from people who realize you don't have to pay to get your home saved. Then, the service collapses and what do you say when a responsible former subscriber's place goes up in flames as a result?
It's not like these services just let you forget to pay, either. They do everything they can to make sure you know what it means if you haven't and don't pony up your equivalent-of-a-cup-of-coffee-a-week.
That was funny in a sense, but also very very sad. There is a growing population that would have a very hard time using a pen and paper. I know you were joking, but I see this as a problem. The more one grows to rely (as opposed to just using) technology the more one is incapable of taking care of oneself when deprived of said technology.
Translation: Get off my lawn.
I'm all for tech obviously or I wouldn't be in IT and wouldn't post here, but your 'joke' just underlines how weak and soft people are growing as they increasingly rely on tech that could go away in a heartbeat.
Translation: Those dratted kids.
One big EMP and there would be a bunch of geeks milling around not quite knowing what to do as they slowly starve to death staring at their smartphones waiting for them to turn back on.
Translation: I've fallen, and I can't get up.
Let's bear in mind, please, that geeks will have no monopoly on starvation and privation if someone starts lobbing EMPs around. There will be bigger problems than kids' unfamiliarity with pen and paper if the pillars of our society are tumbling down around our ears. If your bunker isn't fully stocked and you aren't practicing subsistence agriculture right now, then your post is the height of hypocrisy.
Well, first you have to get a system in place. So you get to pay $BIGNUM for something you need to hack anyway.
(As a side note... unless your post is tongue in cheek... does it constitute a breach of DMCA or similar? Should we be horrified that each system has the same root password as you're implying?)
Of course, if you just generate a patch file with the source changes, and zip that up, it will be even tinier.
Except for that upgrade of the underlying FooLib from 2.1 to 2.2 that's part of your hotfix. Well, all you need then is to just get a patch file for that too, and include that.
And then compile the whole sucker on the other end.
Everyone's got plenty of CPU, right? And we're just about all using trivially decompilable bytecode anyway, so if you make your patchfile based on the source changes after compilation and decompilation, you've got all the right transforms in place to come up with a pretty effectively minimal changeset.
Of course, we have plenty of bandwidth anyway, and programs are small. Media files are not, but I'm not going to get any space savings trying to disassemble that picture of your mom.
Oh noes! Communication networks allow people to communicate with other people!
I used to have a daily (static) stretch routine that has lapsed since I hung up my skates, so I'm looking at this article with interest and trying to match them against my own observations and routine:
1. The purpose of the stretching routine was to allow the muscles to lengthen and reduce the chance of injury that wild flailing contortions on a slippery surface exposes you to.
TFA suggests that muscles are "weakened" (in terms of performance) but does not say that those muscles have been exposed to injury risk. Also, the parts of my body I'm protecting are the non-stretchy bits of ligament and tendon that may see too much load if muscles are too tight.
2. The routine was a set of systematic, static stretches held for a minimum of 30 seconds. But the whole set was always, always, always preceded by a light warmup: jogging, a few pushups, etc.
This is borne out by the article, which said (surprise!) that warmed up muscles work better. In fact, cold muscles are just hard to stretch, and you risk injuring yourself right there.
Dynamic stretching was something I was aware of at the time, but it came with a bit of a warning-- if you don't know what you're doing with exercises that stretch muscles that are under tension, or you're not in peak physical shape, you can hurt yourself pretty fast.
It does sound like there's been progress in this area... it was very hard to find information on "how to do effective dynamic stretching without breaking yourself" five years ago.
Now... as for the "ex" part of "ex-goalie": my first knee injury was an MCL tear on a game in early summer, when I wasn't in a regular stretch routine, when I hadn't followed my regimen properly before game. That emphasizes to me that not following a stretching routine was infinitely worse than a static stretching routine. I won't comment on whether what I did do was optimal-- I suspect it could have been improved.
(FWIW it wouldn't have saved me from knee injuries #2 and #3, patella subluxations that put me out of the sport for good. Turns out I have shallow trochlear grooves and sliding kneecaps are bad if you like butterfly goaltending and dislike obscene amounts of pain.)
So best I can say is that this article's pretty inconclusive about whether static stretching is actually bad. I believe that even if it cuts your muscle output, it's still having an effect in increasing your safe range of motion, and both (a) better than no stretching and (b) more easily managed for an amateur than some potentially aggressive dynamic stretching approaches.
The laundry list of limitations in Qt3 driving the move have long since faded from my memory (though I seem to recall Vista support being a fairly large motivator.) But apart from that, ongoing commercial development requires active support, and Trolltech's support services have long since dropped support for Qt3.
Porting from Qt2 to 3 was a breeze, compared to the move to Qt4. The automated porting tools didn't do much for us, and the Q3Support layer-- while it gave us a good stepping stone-- eventually had to be ripped out almost entirely because we kept hitting all sorts of esoteric bugs that couldn't be solved without porting the code all the way.
To be fair... I like Qt a lot, and it's still my first choice for multiplatform GUI development. (Before many of the platforms sank into obscurity our app suite built from a common C++/STL/Qt codebase onto Windows, Linux, Solaris, HPUX, AIX, Irix and OSF, which still impresses the crap out of me. :) )
Having spent the last seven years using Qt and C++, and the last two comparing that with C#, I'd agree with the original poster: C# is a better choice for fast productivity to a GUI .exe for Windows.
Throw other platforms into the mix and my decision changes, but that's not what he stated, is it?
Qt lost a lot of points in my book for just how much time was destroyed in porting our code to Qt4. Two years later, and we're still asking for bugfixes.
All I can say is... thank god for "wget -c". Their server room must be filling with smoke as I speak.
Nokia doesn't make their money licensing software, and I don't think they want to change that now.
This is the part I disagree with. TT's commercial market may not have been "lucrative", but it was enough to keep the company afloat and growing for the last decade or so. Niche revenue is still revenue and I would be surprised if Nokia decided to simply write it off.
But I do see the upside to Nokia offering a free (beer) license for "its" mobile platform SDK. Less so for a free (speech) license. I don't think they'll discount the existing revenue stream quite so quickly though.
I'm looking more closely at the future of Qt on the desktop. I've been working as a developer at a company that provides a not-insignificant portion of TT's revenue in licensing fees, since the Qt2 days-- and after the pain and suffering of the port to Qt4, this is another bit of disquieting news. I'm not sure TT's new imperial overlords are as interested in the desktop toolkit as the mobile product.
But then, I can only hope they won't be so quick to throw away that revenue stream, either, and keep responding to our bug reports.
It's really awful to have to write a very diplomatically phrased email to a team leader to explain that one of his coders has created an API in which they have consistently and unfailingly used the word "Recieve", and that some day that API will probably be part of what we expose externally, and that you'd really appreciate it being fixed before people actually start using it. But it's even worse when the API is specced in a Word doc and the misspeelings are in there, too.
Worst of all, though, is trying to use the damn API while your brain is distracting you with fits of "I before E except after C!"
None the less, the shame I felt in raising the issue at all was matched only by my disappointment that no one else had caught it already.
Thank you, this is one of the nicest (and most amusing) analogies I've seen for describing the difficulties of concurrency. :)
The babelfished translation makes a few comments about distinctions that make this sound not so bad.
Distinguishing between a 'true invention' implemented on a computer and an existing invention that just happens to be implemented on a computer for the first time is a big one. It means that Joe Q Random can't patent his chopstick indexing program just because noone's ever indexed their chopsticks with a computer before.
(Provided, of course, someone's come up with a chopstick sorting system at all... Um. Excuse me, I'll be right back...)
Two things. The first from gamasutra is a story titled "Xbox Encryption Key Under Brute-Force Hack Attack; Could Take Eons". Sounds to me like it was a noble, but ultimately futile goal.
The second is a comment I made to friends immediately after hearing the story. The Neo Project had essentially just rubbed pig's blood and feces all over itself, and then jumped into the South Pacific and splashed its arms around. Hell, they even SAID on their webpage that at the slightest hint of objection of a legal nature, they'd drop everything.
"So what you're saying," I can imagine a Microsoft landshark responding, "is that, if we tell you to stop... you will? Well, in that case.. Stop!" No doubt the landshark then submitted an expense cheque for several hours of "research".
Why did TNP even bother starting? Call me suspicious, but I think it's a big publicity stunt on TNP's part. They got attention.
We're getting an awful lot of stories hitting Ars Technica and then showing up on Slashdot days later.
/. just for cheap "I got a story posted!" thrills?
I really appreciate new and interesting stuff, but if it's already made its run through other blogs, does it really need someone to pick it up from there and rehash it on
Well, it's not as if David Weber's books are marvels for their subtle and complex characters.
In fact, if WoH is the first HH book you've noticed that the good guys are all really good and honourable and loyal and - occasionally - rapscallions, but nice fuzzy heart-of-gold rapscallions.. and the bad guys are power-hungry, greedy sons-o-thingames willing to climb a mountain of dead bodies to get to the top, or just plain namby-pamby liberal military-hating scumbags who are too stupid to understand political realities... (deep breath, deep breath).. where was I?
I'm a HH fan because the universe has a nice feel to it, Weber is a gifted author when it comes to describing space war, and of course big things happen on a grand scale. It's space opera.
His characters and dialogue really detract from it though. I've noticed between his HH series, and the Starfire books he co-authored with Steve White, a lot of the same characters appear - with different names.
Having played with the ODE...
:)
The parent article is quite correct. If you're doing any solid-body physics based stuff, ODE rocks. Combine it with SDL and OSG and you have the basic tools to produce some really cool stuff. Throw in the Demeter Terrain Engine if you want a bit of scenery to go with it. I've tied all four together for experimenting with what makes a good driver interface for a hovertank.
The Stair-dismount makes good use of joints, and collision detection features of ODE - but even if you don't need these, the force model of ODE is a lot of fun to play with on its own. But if you *are* ambitious, it has specialised joint and suspension-spring models for doing things like wheeled vehicles pretty easily.
With all these tools available under LGPL, those of you like me - who don't like writing a graphics/physics engine so much as actually writing cool simulations with said engines - have a much better point to start from than even 2 years ago.
...Perhaps you could make a social commentary video game where you go into lower class minority neighbourhoods recruiting disenfranchised voters by blowing open their houses and picking up their pixellated arm-waving butts in your helicopter, while dodging bullets being fired at you by the Establishment's tanks, jet fighters and UFOs?
We.. uh.. don't.
I might be wrong, I haven't dealt with that issue directly. The problem had to do with initial loading of data (we deal with as many gigabytes of 3D flow data as the OS, FS, and available resources will let us..) where a couple of very large maps get used and then discarded.
I *think* it's been alleviated by re-engineering that section such that smaller steps are used, so the high-water mark isn't as big.
You misunderstand me - we do strive for const correct programming. My point is, it's pretty difficult sometimes to sift through 6, 10, 14 lines of template name expansion just to discover that you're trying to cast a const iter to a non-const iter. At least it was at first, until you knew what it looked like.
Unless there was a specific requirement and good reason for it, I wouldn't write C++ without STL nowadays. We've been using it for the last 2+ years on about 6 different unix platforms (mostly gcc2.95 over that time) and NT (using VC6.)
In that time we' ve seen a lot of improvement as native compilers for HP, and possibly IBM are catching up and threaten to replace gcc for builds on those systems.
VC6 is a real catch.. their STL implementation is only borderline usable. The solution to this was to introduce stlport into the mix, at least for our win32 builds.
Some issues we've had:
- verbose syntax (once your finger macros catch up, it's okay)
- EXTREMELY verbose compile error statements - especially when using a sufficiently complex STL object (vector of strings, or something) and doing something like attempting to use a const iter in a non-const way produces monstrosities like:
passing `const string' as `this' argument of `class basic_string,__default_alloc_template > & basic_string,__default_alloc_template >::operator =(const basic_string,__default_alloc_template > &)' discards qualifiers
(and that's a simple one.)
- Bugs on various platforms, including the lovely uselessness of VC6 STL
- Difficulty of examining data in debuggers - ddd+gdb gets a right ugly mess
- Memory High-water-marks: Some things don't really free the memory you want them to free, just hold onto it for next time. We've discovered this when we create stupidly-large temporary maps, and then delete them.
- Various little gotchas like the dangers of using remove() algorithms, being aware what map's operator[] does, etc.
- Inconsistencies between std::string and the rest of the STL
But to try and be less negative:
- STL has made handling data within a C++ program much more pleasant. For us, STL is fast and efficient, and has probably saved us many programmer-months in the debugging and development time required to use traditional C/C++ data structures. Plus, once you get into the mindset used by STL, it gets more and more powerful every time you read another part of the documentation.
Try playing goalie (of the hockey variety.) Not only will it suddenly become in your best interest to get in good cardio shape as well as maximize your flexibility.
:)
It will also give you welts, bruises, and knee pain that will make you forget all about your back.
(Actually, I've lost some 10lb, lowered my body fat % very well, and eventually my flexibility caught up with the contortions I was doing and the knee pain stopped. All that over a single winter. Back pain? Can't remember the last time I had back pain. Actually, I can... it was when I discovered I was the world's worst horserider.)
I'm sorry, I don't buy it.
Jamie, in the article header, you state that your analysis follows.
What follows isn't an analysis, it's preaching. What's more, it's using an issue relevant to Slashdot (age restriction of violent computer games falls in that category, I think) that's only peripherally related to something you obviously feel very strongly about, as an excuse to preach about your pet issue.
Man, I need a synonym for "preach" and quick - but you preach for several paragraphs about the cruel slaughter of animals by all us bad carnivores. Your "analysis" is nothing more than "How can this be taking place when this other thing hasn't been corrected?"
Not relevant. And a flagrant abuse as a staffer at Slashdot too.
Can someone moderate Jamie's whole 'analysis' downwards as irrelevant flamebait, please?
--Chris
I was impressed by one part of the "horrifying" cinematography.
:). It's harder to trick the human eye in areas it's intimately familiar with. Human forms and faces still aren't convincing when done straight up with CGI. So it's still a challenge.
/not once/ - in this entire trash-heap of a movie, plot holes oozing all over the place, did I ever have a moment where I looked at the 10 foot tall beasties and the 6 foot tall oo-mans and think "this looks contrived". I realised afterwards that the one thing I was convinced about was that John Travolta really /was/ 10 feet tall (talk about being larger than life!) and looked perfectly natural in those big ol' clown shoes of his.
In today's age of computer graphics, some really amazing special effect lineups are possible. Everything from massive heart-pounding battle scenes to heart-renching impossible vistas. BE worked towards this, not really leading the way, but still doing a respectable job.
The one thing I was impressed by, though, at the end of the movie was their achievement tackling a problem still difficult because of its very plausableness (sp?
What was it?
The size difference between the Psychlos and the humans. Not once -
The director and technical staff achieved this through a pretty elegant set of means, not the least of which was very clever camera work. They achieved this one goal masterfully.
There you go. Top that.
--Tiger