> Can these cards to (sic) programmable shading like RM can? No.
What do you thing Cg is? A brand of soap?
There're a few remaining areas that the upcoming generation of cards can't do as well as Renderman and friends, certainly. But I think you're misjudging how quickly consumer graphics hardware is moving. And, quite frankly, movie CG is pretty much standing still.
> Fortunately for consumers, though, VISA and MasterCard have voluntarily limited debit card > liability to the same $50 limit that exists for credit cards.
So you should only worry if your debit card can be used as a pseudo-credit card, with signature only and no PIN, *and* it's not MC/VISA. I'm not aware of any such cards, but doubtless there are some out there.
Also, with ATM cards (or d/c card used as an ATM card), the limit is $50 if you report the card theft within two days, $500 otherwise. Anything stolen after you report the theft is covered regardless.
Or they're foreigners working in the States with no credit record. I've been here for five years, currently have a pretty good income, and I would still get turned down for any credit card I applied for, 'cause I've never been in debt here.
Credit cards are only cheaper in the US because it's in the interest of the financial institutions for them to be so. Most people fuck up enough with them at some point that the bank winds up making money off it. It only takes a missed payment or two.
If what you said was really true for the average US citizen, debit cards would be cheaper in terms of up-front costs.
No, no -- not porn: PC/console games. Go look at how the stock prices of EA, Activision, etc. have done over the last few years compared to the rest of the tech industry. I'm working for a studio that's hired several new people pretty much every week for the last year or so.
If you're interested in engineering positions you need experience or to otherwise be pretty damn good. But good IT people and network people are needed too, especially with all the online stuff going on. Plus, it seems to be a trend that they throw a lot of people at a product to get it to ship date over the last six months of the cycle.
Plus, although it's fast moving and often stressful, it's damn fun a lot of the time. Give me coding explosions over database work any day of the week.
Well, try getting some relatively recent: it takes about 3s (4 bounces) on my 733 G4. That's about the same speed as Mozilla on a 1Ghz pentium/W2000. (IE5 of course preloads on launch under windows 2000, which is presumably why it takes so long to log in =P.)
I'm running a quicksilver 733Hz G4, OSX 10.1.3, and right next to it a Dell Dimension 4100, 1Ghz P3. I'm on a Pacbell DSL link.
I loaded www.cnn.com and www.apple.com under both IE and moz (9.9) under both machines.
For cnn.com, IE5 and moz on the Dell were about the same, around 2s. (Moz was the fastest to get the banner ad up, maybe IE5 was fractionally quicker overall. Very hard to tell. IE5 had the worst outlier though -- one time it took 5s.)
Moz 9.9 OSX was around 2.5-3s, and IE5 on the Mac was slowest -- 3-4s.
All browsers loaded the Apple page pretty much instantaneously. I couldn't tell the difference.
Lesson #1: use Mozilla under OSX; it's been getting faster with each point release, while IE5's remained static. IE5 can be sluggish at times.
Lesson #2: there really isn't that much of a difference between the machines. I do a fair bit of surfing on both, and they're literally side-by-side, hooked up to the same monitor. Up until now they'd always seemed about the same speed, surfing-wise, to me. So I was taken aback by the article -- and after testing, I guess the OSX browsers are a *little* slower, but not so's you'd notice much.
Mind you, I do have plenty of memory. Perhaps the iMacs were hitting the VM a little hard? Or, the pixmaps for all those pretty alpha-blended graphics probably add up. I believe there's an option to store them compressed in memory to speed things up on low memory machines, probably mentioned on one of the numerous OSX hint sites.
So... by halfway through the decade, windows will finally get Aqua-style full-alpha compositing in the windowing system, and they'll do it by requiring a graphics card? That just sounds lazy. Hell, most (all?) games are doing their UI work like that *now*. (Partly 'cause DX8 makes using GDI so hard.)
Also, people have been trying to come up with a 3D shell for years. I haven't seen anything worth using yet. Partly because of reasons others have alluded to: as soon as you start rotating or warping your pretty bitmaps, you lose one-to-one pixel correspondence, and they start looking horrible, even with mip-mapping and good filtering.
Every tech company I've worked at in the States has had around a 40-50% foreign engineering crew. Same usually goes for CS graduate students.
I know a number of people who cancelled their IEEE membership over the H1-B campaign, and I'm betting many more will cancel over this. The IEEE seems to have forgotten who its members are.
As others have pointed out, it's a horses for courses thing. GUI IDEs have tended to get new features like syntax highlighting and symbol lookup completion/browsing first, but hell, even versions of vi have syntax highlighting these days. Plus symbol browsing in MSVC just breaks on large projects -- it's best to force it off. Doxygen has made more of a difference to my ability to quickly navigate a large code base than any IDE ever did.
The one exception is this: almost all graphical IDEs come with a kick-arse visual debugger. It is so much easier to track down a bug by stepping through code with a decent variable-watch window and all the other bells and whistles you get that it's not even funny. Unix command-line debuggers are back in the stone ages by comparison. You get forced back into debugging-by-printf/cout hell.
When I'm doing Linux dev work, I use makefiles and a simple text editor, but for debugging I fire up kdbg (used to be DDD), just because it's so hard to go back to command-line debuggers.
Oh, and veering wildly OT: Good lord, are we *ever* going to get precompiled headers for g++? It's pretty much useless for large projects without.
I see this "If you code in DirectX, at least it will work on all cards" canard repeated so often, I can only marvel at Microsoft's propaganda machine and the essential stupidity of mankind. Why do you think so many new DirectX games fail to work under a number of cards until they release patches?
As someone who's coded in both (and Direct X for a game that must support a wide range of cards), an OpenGL program is far more likely to work on a given range of cards if you haven't coded in explicit support for those cards. The equivalent DX program will require far more setup and test code.
People don't seem to understand this about Direct X: It supplies a feature set, but different cards implement different parts of that feature set. You have to *explicitly test* almost any feature you can name to see if the card can support it, via "capability bits". Try getting hold of the DX caps viewer, and you'll be able to see just how many of them there are.
In fact, it's worse than that. Because old drivers often lie about their caps. (Hello Virge.) Also, the caps, especially the texture caps, often don't map nicely to a card's capabilities. So the only real way of seeing whether a particular texture stage setup will fly is to try it, and see if the driver rejects it. Plus there are the weird-arse ones like the NVIDIA 8-stage setup where they jump through the hoops of the DX API to expose their register combiner functionality. (Functionality that is directly exposed in OpenGL, BTW.) Cards also have different capabilities depending on which release of direct X their drivers support. So the same card can report completely different caps depending on driver version. It's a support and programming nightmare.
The only real way to deal with all this is know what each card is capable of, read the manufacturer's release materials, and spend time on the DX mailing list. You spend a lot of time programming a particular effect in a number of different ways, and hope like hell all your combinations cover all the cards out there. You cannot guarantee a particular card will work with your app until you test it.
You may assume that DX provides fallback paths for some features, but you'd be wrong. Or where it does, it does it in a braindead way; because your card lacks fabby next-generation feature X, and you requested it, wham, it emulates the *entire* pipe in software instead of just feature X. You lose T&L, and your framerate slows to a crawl. Then you either code your own pipe to do feature X on the CPU and then hand off properly to the card, or you just go without. Either way involves a lot of testing code. OpenGL is much, much better about falling back gracefully.
I'm also not clear on why people think DirectX has a technical edge. Microsoft do a fine job of going to the current hot hardware vendor, incorporating their upcoming features in their API, and then making a lot of noise about it. But you could access vertex shaders on the GeForce3 from OpenGL on the Mac before you could ever use them from DX. The OpenGL extension mechanism means that when a part comes out, you almost immediately have access to its new features, rather than having to wait for the next DX rollout. (Remember, NVIDIA had to install a "back door" to provide access to the full register combiner functionality of geforce1-2 cards from DX. Many people don't even know it exists.) Go to NVIDIA's web site and ponder how many of their tech demos these days are in OpenGL.
The only thing DirectX has going for it, its so-called unified API, makes no difference at all in the end. You end up doing exactly what you'd do in OpenGL -- testing for certain cards, and using their exposed abilities if they exist. Writing a lot of fallback code. In the end, you're better off going with the card manufacturer's APIs, IMHO.
Think of it this way: rather than exposing a unified API, DX exposes *every possible API*. So many wonderful standards to choose from! If you're a unix guy: DX8 is the X11 of the 3D graphics API world.
A.
P.S. Sheesh, I haven't even touched on the headache that is resource management in DX.
P.P.S As someone who has to deal with all this shit (card compatibility), I'm a mite touchy on the subject =)
Graphics companies. Animation companies, effects houses, etc. etc.
More of them are unix-based than you might think (irix!), and they're almost all migrating to Linux. (Which has saved their collective arses from having to migrate to NT, shell scripts and all.)
A well-done commercial 2D paint program for Linux makes more sense at this stage of the game than, say, Office-like software.
Fantastic. I see Microshaft are bringing the ethics they honed in the computer industry to journalism.
I realise it's originally a ZDNET article, but most media companies have this little thing where they note conflicts of interest. Like adding a tag line such as, "MSNBC is partly owned by Microsoft, who make a competing operating system, Windows."
You're missing one thing -- DirectX. They can concentrate on getting the card up and running on OpenGL & the Mac first and earning some dosh before having to turn to writing DX drivers. Which is no picnic. (Though at least the lucky bastards have access to source.)
Slashdot Mirror
> Can these cards to (sic) programmable shading like RM can? No.
What do you thing Cg is? A brand of soap?
There're a few remaining areas that the upcoming generation of cards can't do as well as Renderman and friends, certainly. But I think you're misjudging how quickly consumer graphics hardware is moving. And, quite frankly, movie CG is pretty much standing still.
A.
If you actually read that page, you'll see this:
> Fortunately for consumers, though, VISA and MasterCard have voluntarily limited debit card
> liability to the same $50 limit that exists for credit cards.
So you should only worry if your debit card can be used as a pseudo-credit card, with signature only and no PIN, *and* it's not MC/VISA. I'm not aware of any such cards, but doubtless there are some out there.
Also, with ATM cards (or d/c card used as an ATM card), the limit is $50 if you report the card theft within two days, $500 otherwise. Anything stolen after you report the theft is covered regardless.
A.
Or they're foreigners working in the States with no credit record. I've been here for five years, currently have a pretty good income, and I would still get turned down for any credit card I applied for, 'cause I've never been in debt here.
Credit cards are only cheaper in the US because it's in the interest of the financial institutions for them to be so. Most people fuck up enough with them at some point that the bank winds up making money off it. It only takes a missed payment or two.
If what you said was really true for the average US citizen, debit cards would be cheaper in terms of up-front costs.
A.
No, no -- not porn: PC/console games. Go look at how the stock prices of EA, Activision, etc. have done over the last few years compared to the rest of the tech industry. I'm working for a studio that's hired several new people pretty much every week for the last year or so.
If you're interested in engineering positions you need experience or to otherwise be pretty damn good. But good IT people and network people are needed too, especially with all the online stuff going on. Plus, it seems to be a trend that they throw a lot of people at a product to get it to ship date over the last six months of the cycle.
Plus, although it's fast moving and often stressful, it's damn fun a lot of the time. Give me coding explosions over database work any day of the week.
A.
Actually, mozilla has a nascent version of that now: Tools/Download Manager. Cool, eh! I didn't notice it until just recently; a pleasant surprise.
A.
Certainly! Just send me your credit card number =)
A.
Well, try getting some relatively recent: it takes about 3s (4 bounces) on my 733 G4. That's about the same speed as Mozilla on a 1Ghz pentium/W2000. (IE5 of course preloads on launch under windows 2000, which is presumably why it takes so long to log in =P.)
A.
I'm running a quicksilver 733Hz G4, OSX 10.1.3, and right next to it a Dell Dimension 4100, 1Ghz P3. I'm on a Pacbell DSL link.
I loaded www.cnn.com and www.apple.com under both IE and moz (9.9) under both machines.
For cnn.com, IE5 and moz on the Dell were about the same, around 2s. (Moz was the fastest to get the banner ad up, maybe IE5 was fractionally quicker overall. Very hard to tell. IE5 had the worst outlier though -- one time it took 5s.)
Moz 9.9 OSX was around 2.5-3s, and IE5 on the Mac was slowest -- 3-4s.
All browsers loaded the Apple page pretty much instantaneously. I couldn't tell the difference.
Lesson #1: use Mozilla under OSX; it's been getting faster with each point release, while IE5's remained static. IE5 can be sluggish at times.
Lesson #2: there really isn't that much of a difference between the machines. I do a fair bit of surfing on both, and they're literally side-by-side, hooked up to the same monitor. Up until now they'd always seemed about the same speed, surfing-wise, to me. So I was taken aback by the article -- and after testing, I guess the OSX browsers are a *little* slower, but not so's you'd notice much.
Mind you, I do have plenty of memory. Perhaps the iMacs were hitting the VM a little hard? Or, the pixmaps for all those pretty alpha-blended graphics probably add up. I believe there's an option to store them compressed in memory to speed things up on low memory machines, probably mentioned on one of the numerous OSX hint sites.
A.
So... by halfway through the decade, windows will finally get Aqua-style full-alpha compositing in the windowing system, and they'll do it by requiring a graphics card? That just sounds lazy. Hell, most (all?) games are doing their UI work like that *now*. (Partly 'cause DX8 makes using GDI so hard.)
Also, people have been trying to come up with a 3D shell for years. I haven't seen anything worth using yet. Partly because of reasons others have alluded to: as soon as you start rotating or warping your pretty bitmaps, you lose one-to-one pixel correspondence, and they start looking horrible, even with mip-mapping and good filtering.
A.
Yup. Dumb, dumb and dumber.
Every tech company I've worked at in the States has had around a 40-50% foreign engineering crew. Same usually goes for CS graduate students.
I know a number of people who cancelled their IEEE membership over the H1-B campaign, and I'm betting many more will cancel over this. The IEEE seems to have forgotten who its members are.
A.
Good lord. This was marked +3 informative at one stage.
Clue: lzip is lossy compression =).
A.
It's for the Sims only. The Sims plus expansion packs long ago became the best selling franchise, blowing away Myst + Riven etc.
A.
The one exception is this: almost all graphical IDEs come with a kick-arse visual debugger. It is so much easier to track down a bug by stepping through code with a decent variable-watch window and all the other bells and whistles you get that it's not even funny. Unix command-line debuggers are back in the stone ages by comparison. You get forced back into debugging-by-printf/cout hell.
When I'm doing Linux dev work, I use makefiles and a simple text editor, but for debugging I fire up kdbg (used to be DDD), just because it's so hard to go back to command-line debuggers.
Oh, and veering wildly OT: Good lord, are we *ever* going to get precompiled headers for g++? It's pretty much useless for large projects without.
A.
A.
"Everything in OpenGL is different for different cards. If you code in DirectX, at least it will work on all cards, even if only on Windows (so far)."
I was (trying to) say that in the end there's no difference. You still have to pretty much test per-card.
Jesus. I don't even have a fucking kettle.
A.
I see this "If you code in DirectX, at least it will work on all cards" canard repeated so often, I can only marvel at Microsoft's propaganda machine and the essential stupidity of mankind. Why do you think so many new DirectX games fail to work under a number of cards until they release patches?
As someone who's coded in both (and Direct X for a game that must support a wide range of cards), an OpenGL program is far more likely to work on a given range of cards if you haven't coded in explicit support for those cards. The equivalent DX program will require far more setup and test code.
People don't seem to understand this about Direct X: It supplies a feature set, but different cards implement different parts of that feature set. You have to *explicitly test* almost any feature you can name to see if the card can support it, via "capability bits". Try getting hold of the DX caps viewer, and you'll be able to see just how many of them there are.
In fact, it's worse than that. Because old drivers often lie about their caps. (Hello Virge.) Also, the caps, especially the texture caps, often don't map nicely to a card's capabilities. So the only real way of seeing whether a particular texture stage setup will fly is to try it, and see if the driver rejects it. Plus there are the weird-arse ones like the NVIDIA 8-stage setup where they jump through the hoops of the DX API to expose their register combiner functionality. (Functionality that is directly exposed in OpenGL, BTW.) Cards also have different capabilities depending on which release of direct X their drivers support. So the same card can report completely different caps depending on driver version. It's a support and programming nightmare.
The only real way to deal with all this is know what each card is capable of, read the manufacturer's release materials, and spend time on the DX mailing list. You spend a lot of time programming a particular effect in a number of different ways, and hope like hell all your combinations cover all the cards out there. You cannot guarantee a particular card will work with your app until you test it.
You may assume that DX provides fallback paths for some features, but you'd be wrong. Or where it does, it does it in a braindead way; because your card lacks fabby next-generation feature X, and you requested it, wham, it emulates the *entire* pipe in software instead of just feature X. You lose T&L, and your framerate slows to a crawl. Then you either code your own pipe to do feature X on the CPU and then hand off properly to the card, or you just go without. Either way involves a lot of testing code. OpenGL is much, much better about falling back gracefully.
I'm also not clear on why people think DirectX has a technical edge. Microsoft do a fine job of going to the current hot hardware vendor, incorporating their upcoming features in their API, and then making a lot of noise about it. But you could access vertex shaders on the GeForce3 from OpenGL on the Mac before you could ever use them from DX. The OpenGL extension mechanism means that when a part comes out, you almost immediately have access to its new features, rather than having to wait for the next DX rollout. (Remember, NVIDIA had to install a "back door" to provide access to the full register combiner functionality of geforce1-2 cards from DX. Many people don't even know it exists.) Go to NVIDIA's web site and ponder how many of their tech demos these days are in OpenGL.
The only thing DirectX has going for it, its so-called unified API, makes no difference at all in the end. You end up doing exactly what you'd do in OpenGL -- testing for certain cards, and using their exposed abilities if they exist. Writing a lot of fallback code. In the end, you're better off going with the card manufacturer's APIs, IMHO.
Think of it this way: rather than exposing a unified API, DX exposes *every possible API*. So many wonderful standards to choose from! If you're a unix guy: DX8 is the X11 of the 3D graphics API world.
A.
P.S. Sheesh, I haven't even touched on the headache that is resource management in DX.
P.P.S As someone who has to deal with all this shit (card compatibility), I'm a mite touchy on the subject =)
A.
Moderators, crack. Crack, moderators. Shake hands, please.
More of them are unix-based than you might think (irix!), and they're almost all migrating to Linux. (Which has saved their collective arses from having to migrate to NT, shell scripts and all.)
A well-done commercial 2D paint program for Linux makes more sense at this stage of the game than, say, Office-like software.
A.
Oh wait...
A.
I realise it's originally a ZDNET article, but most media companies have this little thing where they note conflicts of interest. Like adding a tag line such as, "MSNBC is partly owned by Microsoft, who make a competing operating system, Windows."
A...
A57 gets overexcited
A56.
Cheap at... well... one twelth the price.
A.
A.
(Sorry. If you work in 3D it's hard not to twitch uncontrollably when reading that question.)
A.