The world needs another proprietary language like a hole in the head. Cg was created to reinforce NVIDIA's (then) lock on high-end consumer 3D and to abstract away the wildly differing capabilities of underlying hardware (thus encouraging developers to support the top-of-the-line, high-profit-margin chips without shutting out the huge installed base of older chips).
The first of these is in nobody's interest except NVIDIA. The second is a noble ideal, but very hard to pull off; the range of capability is just too great. It would have made more sense to wait a couple of years until the massmarket went fully-programmable. And there are STANDARD, vendor-neutral alternatives coming in the very very near future, notably the high-level OpenGL glslang.
Whatever their marketing may say, Cg will *never* be a level playing field for other IHVs. Thanks all the same, but we do not need, or want, another GLIDE.
Re:GCC and ANSI C standards
on
The Cg Tutorial
·
· Score: 2, Informative
The current development version of GCC (3.3) *does* have support for automatic vectorization (i.e. using SIMD instructions where appropriate). I'm not sure whether you need to help it out by flagging decls with GCC-specific attributes, but it's definitely there.
As others have said, Cg is not an extension of C, and GCC will never and should never support it.
The trouble with goggles, or anything that fills a large angle of view (e.g. IMAX) is that they're compelling and immersive in a way that smaller displays can't really match. Which is great for entertainment, but potentially very dangerous in situations where the augmented stuff is not 100% trustworthy and ought to be treated with some degree of healthy scepticism. Maybe the AR overlays could be drawn in luminous flamingo pink or something, just to make damn sure you didn't forget what was what.
I remember a driver in Germany a couple of years back who drove though a couple of barriers, past several yelling workmen and into a river. All because his in-car GPS navigation was telling him that there was a completed bridge there. And that was a just a teeny little display.
(Side note: "removing" mountains sounds like a truly horrible idea. I have vivid memories of playing the excellent flight sim EF2000 - this was back in the days of software rendering when depth-buffering was still something to be avoided. So the engine just drew the terrain first, and buildings afterward, because, hey, buildings are on top of terrain, right? Unfortunately this didn't cope with occlusion, and I lost count of the number of times I crashed into a bleedin' great hill while on a bee-line for an airfield that was clearly visible right in front of me...)
Not a bad thought, but as other posters have pointed out there are still far too many other ways for a hacked renderer/driver to distinguish between "world" and "models". Texture binding being one of the most obvious ones.
<nitpick>I'd have thought the wireframe hack would be via glPolygonMode rather than glBegin, but what the hey.</nitpick>
This is simply untrue, either from the historical or logical angles. Overwhelming (nuclear) US weaponry did not prevent proliferation to the Soviet Union, China, the UK, France, SA, Israel, India, Pakistan. The list is only going to get longer. (Well, apart from SA.)
Logically, overwhelming weaponry of any kind encourages WMD proliferation as the only way to preserve national sovereignty in the face of obscenely well-armed aggressors. WMD deterrence does not require parity, or anything even close to parity. That's the whole point. The level at which WMD capability becomes an effective deterrent is very low.
In the coming years, I'd imagine that anyone labelled a "rogue state" will take a long hard look at what happened to Iraq, and what didn't happen to North Korea, and start building themselves WMD as fast as humanly possible.
With any number of rogue nations and
terrorist groups developing ballistic missiles
Terrorist groups? Developing ballistic missiles? Does anybody really believe that a terrorist group, however well funded, could pull this off? Or that they'd want to, given that a $10 suitcase can do the job just as well?
This sounds like floundering to me. They've built a solution to the wrong problem and are desperately hoping that nobody notices.
> The Pentium IV is designed to get big megahertz > at the expense of actual performance; why would > Intel throw away their chip's advantage like that?
Maybe because their upcoming Banias chips will follow AMD's lower-MHz/higher-perf approach. So Intel marketing will *have* to start downplaying MHz to sell the things, no?
> I don't know of any compiler that is 100% compliant
I think the EDG frontend is pretty much there these days. I don't doubt it still has the odd bug, but they do now have an implementation of "export", which has been the real ball-and-chain attached to the leg of any team attempting to hit full compliance. The Comeau compiler (www.comeaucomputing.com) uses this frontend.
Every indication is that the upcoming 7.1 release of the MS C++ compiler will be very good indeed; possibly better than G++. Their attitude to ANSI has really come on in leaps and bounds; I've heard from several sources that even the alpha could build Loki, Boost and Blitz without hacks. Loki in particular is notorious for killing compilers; it is to C++ what TeX was to Pascal.
> Good C++ programmers realize that there is nothing wrong with using C constructs such as null-terminated strings and printf
For quick hacks, sure. For big, critical production systems, I'd say that using printf is verging on professional negligence in this day and age.
> It's obvious the reviewer needs to get a dose of programming in the real world
Opera 7's M2 mail client is nice, although it does take some getting used to. I was quite disoriented at first as well, but after using it for a short while I'm a convert.
Fundamentally, M2 doesn't treat your email like a hierarchical filesystem, it treats it like a relational database. So there's one big repository, and any number of views (==queries) onto it; you don't have to decide whether that mail belongs in "MailFromBob", or "MailAboutFoo", or "MailINeedToDoSomethingWith". It can appear in all of them, and for the standard views (by contact, by label etc) it'll all happen automagically.
Couple of minor gripes - import from Mozilla mail isn't perfect (empty trash and compact folders FIRST), and it gratuitously stops dead if you have SMTP username/password specified and your relay server doesn't need them, but overall it's very cute.
If you're worried about your mail getting locked up in a nonstandard format - AFAICT the repository is stored in plaintext mbox format. Indices are binary, but what the hey.
The speed difference is NOT small enough. Opera has a very clean and convenient UI for controlling image loading; AFAIK neither IE nor current builds of Mozilla do. When you're browsing today's ludicrously overadorned websites over a 56k dialup connection, Opera is an honest-to-god order of magnitude faster.
Curved surface rendering will still be drawing triangles, they'll just be getting tesselated in hardware rather than software. This exists already for some special cases; take a look at ATi's pn_triangles GL extension, for instance, which automatically rounds out triangles by inferring curvature information from the supplied vertex normals. More general (and programmable) hardware tesselation *will* come soon - it's not a very big step from the vertex shaders already evolving. At this point it's largely a question of folks trying to decide what a general tesselation interface should look like; there's no real hardware stumbling block.
Flat shading is the most primitive model there is, btw. And Phong shading is already available on consumer hardware, and has been for some time, using cube maps.
As I'd expect more people to have pointed out, the whole "who needs 700 fps?" argument is bogus. It's all about upping image quality while *maintaining* that framerate.
<confession>Okay, I don't actually know LaTeX, so there's a very good chance I'm about to look stupid...</confession>
...but isn't LaTeX designed for print? Fixed page size, for visual reading only. Does it address scalability for different display sizes, from 21" monitors to PDAs? Does it support semantic tagging for accessibility support? If not, it can't and shouldn't replace xhtml.
Might be nice to replace PDF as a web-distributable print-quality format, though. I hate PDFs.
Opera is NOT 100% compliant. There are a number of outstanding bugs which have been known for some time and which were still not addressed in the last release. One of these bugs is serious enough to prevent us from supporting Opera in the Web application we're currently developing.
Don't get me wrong; I like Opera, and am posting from it now. But it ain't perfect.
If it were as easy clicking a button on your MP3 player to send a 'tip' to the artist/publisher, people would do it.
Do you really think so? Really? We'd tip the artist, certainly. But exactly what useful service is the publisher providing in this scenario? Hmm.
The historical functions of publishers have centred around promotion and distribution. Distribution is no longer a relevant issue. Are we really going to be happy about paying for the privilege of receiving advertising?
As I see it, once broadband hits everywhere, music publishers will have no useful role to play any more. They don't like this, because as things stand they're still making money. What do you expect them to do, file for bankruptcy while the shekels are still rolling in?
Some interesting tidbits here.
I have a mail.com account with a fairly unlikely address - not likely to be in a dictionary, and too long for the AAAA-ZZZZ approach. I don't seem to get "random" spam, but what I've noticed is that every time I get a real message, I get a spam message soon afterwards. One-for-one correspondence. Coincidence, or has anybody else noticed this?
>60fps isn't the point. The point is being able to do more at 60fps. Like twenty-pass shaders with motion blur and depth of field. I'd go into more detail, but this question is put up and knocked down so regularly that I suspect you're just trolling.
The optional imaging subset in OpenGL 1.2 already allows cards to accelerate image processing tasks using arbitrary convolution filters (though IIRC filter size is restricted). I think some 3Dlabs hardware implements this; their drivers certainly do.
You can already play Game of Life with hardware acceleration. There's a solution using the stencil buffer in the OpenGL Red Book.
Gfx cards deal pretty much exclusively with 4x4 matrices and 4-element vectors. No IHV is going to cram a general matrix processor into their silicon just for a laugh.
I know this may come as a shock, but some strange people do use graphics cards for other things than Quake. Seriously, they do. Honest.
For anybody interested, the basic idea behind "Hyper-Z" is a few years old. The best description I've seen is Hansong Zhang's dissertation (based on a paper he gave at Siggraph '97). He calls it "hierarchical occlusion mapping" - I guess the same ATI marketdroids who gave us "Pixel Tapestry" and "Charisma Engine" were to blame here...
It's an interesting technique, for several reasons. For one, it doesn't require massive amounts of scene preprocessing, which means that you can display much more dynamic worlds than if you were tied to an expensive BSP data structure. For another, at some point in the hopefully not too distant future we'll move from Z-buffers to A-buffers (conceptually, a linked list of depth values per pixel) to remove the ugly need to sort transparent polys. For obvious reasons, this is going to stress the hardware, and a way to perform en masse depth rejections would be a great help.
Piffle. In physical terms, an increase in entropy (that's entropy, not freedom) is associated with a decrease in usefulness as order is lost. So to fit your argument MP3s should steadily transmute into white noise as they percolate through the net.
Taking a muddled metaphor and calling it a "fundamental law of nature" does not a convincing argument make.
Might it not be a good idea to release a free edition of Qt for Win32? Now that the source is GPL'ed there's nothing to prevent somebody else from building a workalike implementation layer, but using TrollTech's source would make for much cleaner development and easier upgrades to the Professional edition.
I know a lot of the/. crowd consider the whole issue of Windows ports to be beneath contempt, but there are some useful OSS projects using Qt (Doxygen springs to mind) which supply binaries for Win32 but can't be built under Win32 unless you sell off some internal organs and buy a pro license. More testing eyeballs are all very well, but it seems a shame to restrict your developer base like this.
WRT hardcore flight sims at least, I doubt that sales are actually shrinking that much. I suspect the problem is more that the target market for these games was very close to the early-adopter PC demographic; somewhat anal types who like the challenge of fiddling around with horribly complex systems.
So most of the potential market was tapped pretty early on; the explosion of PC use among Joe Public hasn't brought many new converts. Meanwhile, of course, dev costs are skyrocketing just like any other genre. From a publisher's POV this plummet in market share and ROI looks like an out-and-out loser.
Side note - am I the only one who's sick of people saying over and over again with a wistful sigh, "Remember when gameplay was all that mattered...?" Get real. There was never a Golden Age. Remember Sturgeon's Law, "90% of anything is crap". Most games sucked in the 80s too, it's just that we've forgotten those and remember the good ones. Designers then tried to make their games look as good as possible, it's just that back then "possible" didn't go very far. And designers now aren't just forgetting to check the "Good Gameplay" box in Microsoft GameWizard. Gameplay is HARD.
where C++ templates result in code bloat by producing a copy of the generic class for every concrete instance
To be fair, you can often avoid this in C++, using the same technique that you describe for GJ. Basically, where you have a collection of typed pointers, you can implement all functionality in an instantiation for void* and then subclass it with a strongly-typed casting wrapper. Stroustrup mentions this technique in CPL as an effective way to reduce bloat.
even hardware ray tracing (the number of rays you have to trace is 1st order proportional to the number of screen pixels which as I pointed out above isn't going up particularly fast - there has to be a cross-over point where this becomes usefull)
Um. Number of rays may be proportional to number of pixels (which, as you say, is fairly fixed), but the cost of evaluating intersections for each ray is proportional to the complexity of scene geometry (which is going going through the roof).
I'd agree that bandwidth constraints are important, but I don't think they're the end of the world. At the moment (on-card) bandwidth primarily limits framebuffer read/write and texture sampling; these have been major issues in the past because they were usually the bottlenecks in software 3D, but the hardware focus now is shifting more towards single-pass multitexture (which can actually reduce bandwidth requirements in some cases), per-pixel shading (which is more computation than memory access) and on-card vertex manipulation (which is a really wide-open field, and is already causing historical API models to creak a bit at the seams).
The comparison with 2D graphics is possibly misleading - 2D hit a plateau because it became "fast enough" for just about anything. I mean, once you can comfortably redraw the entire screen every frame there's nowhere much to go without branching off into Aqua-style eyecandy silliness. Maybe one day 3D will be "fast enough", but I don't see it anytime soon. There are ways around the bandwidth wall if you want to badly enough; move blending ops into RAM as some companies have done to avoid the read-modify-write round trip, or use a Talisman-style tiled architecture and parallel pipelines.
Consumer 3D acceleration has advanced at a phenomenal rate in the past few years, for two main reasons.
Firstly, until now everyone has been chasing SGI's taillights. SGI and OpenGL pretty much defined how to do fast 3D, so hardware and API designs have evolved toward that goal in a fairly consistent manner. (Except for a few unsuccessful oddballs like the NV-1 and D3D-RM.)
Secondly, it started off as a wide-open market with no entrenched leader. Lots of competition, leading to low prices and very fast product cycles.
This picture is starting to change, which is why I wonder whether the rate of progress is going to slow down. Firstly, consumer hardware has now caught up with SGI. SGI's "high bandwidth throughout the box" systems still win for some workstation apps, but there's no gaping chasm in speed or features any more. We're in uncharted territory now, and there's much less agreement about what the next goals should be. If every vendor starts innovating along radically different paths, apps will have a harder time using them all, and without app support the upgrade cycle is broken.
At the same time, the competition is thinning out drastically. ATI is now just about the only significant competitor to NVidia; 3Dfx is just about hanging in there but is suffering from repeated slippages and is going to have a very hard time catching up. These days NVidia is very, VERY influential in defining the direction of Direct3D, and will become more so now that they've been selected for X-Box. Remember that D3D (unlike OpenGL) has no extension mechanism, so a D3D version written to favour one vendor is a huge competitive advantage - if other vendors can't get their features exposed then they've effectively wasted a generation.
I'm a big fan of NVidia. Their hardware is superb, their drivers are excellent, they have a serious commitment to OpenGL and cross-platform support, and they contribute a lot to the graphics community in terms of research. But I'm not sure I'd like to see a total NVidia monopoly on consumer graphics. For that reason, if no other, I hope Radeon does well.
Slashdot Mirror
The world needs another proprietary language like a hole in the head. Cg was created to reinforce NVIDIA's (then) lock on high-end consumer 3D and to abstract away the wildly differing capabilities of underlying hardware (thus encouraging developers to support the top-of-the-line, high-profit-margin chips without shutting out the huge installed base of older chips).
The first of these is in nobody's interest except NVIDIA. The second is a noble ideal, but very hard to pull off; the range of capability is just too great. It would have made more sense to wait a couple of years until the massmarket went fully-programmable. And there are STANDARD, vendor-neutral alternatives coming in the very very near future, notably the high-level OpenGL glslang.
Whatever their marketing may say, Cg will *never* be a level playing field for other IHVs. Thanks all the same, but we do not need, or want, another GLIDE.
The current development version of GCC (3.3) *does* have support for automatic vectorization (i.e. using SIMD instructions where appropriate). I'm not sure whether you need to help it out by flagging decls with GCC-specific attributes, but it's definitely there.
As others have said, Cg is not an extension of C, and GCC will never and should never support it.
The trouble with goggles, or anything that fills a large angle of view (e.g. IMAX) is that they're compelling and immersive in a way that smaller displays can't really match. Which is great for entertainment, but potentially very dangerous in situations where the augmented stuff is not 100% trustworthy and ought to be treated with some degree of healthy scepticism. Maybe the AR overlays could be drawn in luminous flamingo pink or something, just to make damn sure you didn't forget what was what.
I remember a driver in Germany a couple of years back who drove though a couple of barriers, past several yelling workmen and into a river. All because his in-car GPS navigation was telling him that there was a completed bridge there. And that was a just a teeny little display.
(Side note: "removing" mountains sounds like a truly horrible idea. I have vivid memories of playing the excellent flight sim EF2000 - this was back in the days of software rendering when depth-buffering was still something to be avoided. So the engine just drew the terrain first, and buildings afterward, because, hey, buildings are on top of terrain, right? Unfortunately this didn't cope with occlusion, and I lost count of the number of times I crashed into a bleedin' great hill while on a bee-line for an airfield that was clearly visible right in front of me...)
Not a bad thought, but as other posters have pointed out there are still far too many other ways for a hacked renderer/driver to distinguish between "world" and "models". Texture binding being one of the most obvious ones.
<nitpick>I'd have thought the wireframe hack would be via glPolygonMode rather than glBegin, but what the hey.</nitpick>
This is simply untrue, either from the historical or logical angles. Overwhelming (nuclear) US weaponry did not prevent proliferation to the Soviet Union, China, the UK, France, SA, Israel, India, Pakistan. The list is only going to get longer. (Well, apart from SA.)
Logically, overwhelming weaponry of any kind encourages WMD proliferation as the only way to preserve national sovereignty in the face of obscenely well-armed aggressors. WMD deterrence does not require parity, or anything even close to parity. That's the whole point. The level at which WMD capability becomes an effective deterrent is very low.
In the coming years, I'd imagine that anyone labelled a "rogue state" will take a long hard look at what happened to Iraq, and what didn't happen to North Korea, and start building themselves WMD as fast as humanly possible.
Terrorist groups? Developing ballistic missiles? Does anybody really believe that a terrorist group, however well funded, could pull this off? Or that they'd want to, given that a $10 suitcase can do the job just as well?
This sounds like floundering to me. They've built a solution to the wrong problem and are desperately hoping that nobody notices.
> The Pentium IV is designed to get big megahertz
> at the expense of actual performance; why would
> Intel throw away their chip's advantage like that?
Maybe because their upcoming Banias chips will follow AMD's lower-MHz/higher-perf approach. So Intel marketing will *have* to start downplaying MHz to sell the things, no?
> I don't know of any compiler that is 100% compliant
I think the EDG frontend is pretty much there these days. I don't doubt it still has the odd bug, but they do now have an implementation of "export", which has been the real ball-and-chain attached to the leg of any team attempting to hit full compliance. The Comeau compiler (www.comeaucomputing.com) uses this frontend.
Every indication is that the upcoming 7.1 release of the MS C++ compiler will be very good indeed; possibly better than G++. Their attitude to ANSI has really come on in leaps and bounds; I've heard from several sources that even the alpha could build Loki, Boost and Blitz without hacks. Loki in particular is notorious for killing compilers; it is to C++ what TeX was to Pascal.
> Good C++ programmers realize that there is nothing wrong with using C constructs such as null-terminated strings and printf
For quick hacks, sure. For big, critical production systems, I'd say that using printf is verging on professional negligence in this day and age.
> It's obvious the reviewer needs to get a dose of programming in the real world
Now you're just trolling.
Opera 7's M2 mail client is nice, although it does take some getting used to. I was quite disoriented at first as well, but after using it for a short while I'm a convert.
Fundamentally, M2 doesn't treat your email like a hierarchical filesystem, it treats it like a relational database. So there's one big repository, and any number of views (==queries) onto it; you don't have to decide whether that mail belongs in "MailFromBob", or "MailAboutFoo", or "MailINeedToDoSomethingWith". It can appear in all of them, and for the standard views (by contact, by label etc) it'll all happen automagically.
Couple of minor gripes - import from Mozilla mail isn't perfect (empty trash and compact folders FIRST), and it gratuitously stops dead if you have SMTP username/password specified and your relay server doesn't need them, but overall it's very cute.
If you're worried about your mail getting locked up in a nonstandard format - AFAICT the repository is stored in plaintext mbox format. Indices are binary, but what the hey.
The speed difference is NOT small enough. Opera has a very clean and convenient UI for controlling image loading; AFAIK neither IE nor current builds of Mozilla do. When you're browsing today's ludicrously overadorned websites over a 56k dialup connection, Opera is an honest-to-god order of magnitude faster.
Curved surface rendering will still be drawing triangles, they'll just be getting tesselated in hardware rather than software. This exists already for some special cases; take a look at ATi's pn_triangles GL extension, for instance, which automatically rounds out triangles by inferring curvature information from the supplied vertex normals. More general (and programmable) hardware tesselation *will* come soon - it's not a very big step from the vertex shaders already evolving. At this point it's largely a question of folks trying to decide what a general tesselation interface should look like; there's no real hardware stumbling block.
Flat shading is the most primitive model there is, btw. And Phong shading is already available on consumer hardware, and has been for some time, using cube maps.
As I'd expect more people to have pointed out, the whole "who needs 700 fps?" argument is bogus. It's all about upping image quality while *maintaining* that framerate.
<confession>Okay, I don't actually know LaTeX, so there's a very good chance I'm about to look stupid...</confession>
...but isn't LaTeX designed for print? Fixed page size, for visual reading only. Does it address scalability for different display sizes, from 21" monitors to PDAs? Does it support semantic tagging for accessibility support? If not, it can't and shouldn't replace xhtml.
Might be nice to replace PDF as a web-distributable print-quality format, though. I hate PDFs.
Opera is NOT 100% compliant. There are a number of outstanding bugs which have been known for some time and which were still not addressed in the last release. One of these bugs is serious enough to prevent us from supporting Opera in the Web application we're currently developing.
Don't get me wrong; I like Opera, and am posting from it now. But it ain't perfect.
Do you really think so? Really? We'd tip the artist, certainly. But exactly what useful service is the publisher providing in this scenario? Hmm.
The historical functions of publishers have centred around promotion and distribution. Distribution is no longer a relevant issue. Are we really going to be happy about paying for the privilege of receiving advertising?
As I see it, once broadband hits everywhere, music publishers will have no useful role to play any more. They don't like this, because as things stand they're still making money. What do you expect them to do, file for bankruptcy while the shekels are still rolling in?
Some interesting tidbits here. I have a mail.com account with a fairly unlikely address - not likely to be in a dictionary, and too long for the AAAA-ZZZZ approach. I don't seem to get "random" spam, but what I've noticed is that every time I get a real message, I get a spam message soon afterwards. One-for-one correspondence. Coincidence, or has anybody else noticed this?
For anybody interested, the basic idea behind "Hyper-Z" is a few years old. The best description I've seen is Hansong Zhang's dissertation (based on a paper he gave at Siggraph '97). He calls it "hierarchical occlusion mapping" - I guess the same ATI marketdroids who gave us "Pixel Tapestry" and "Charisma Engine" were to blame here...
It's an interesting technique, for several reasons. For one, it doesn't require massive amounts of scene preprocessing, which means that you can display much more dynamic worlds than if you were tied to an expensive BSP data structure. For another, at some point in the hopefully not too distant future we'll move from Z-buffers to A-buffers (conceptually, a linked list of depth values per pixel) to remove the ugly need to sort transparent polys. For obvious reasons, this is going to stress the hardware, and a way to perform en masse depth rejections would be a great help.
... am I the only one wondering how you'd set a flamethrower to "stun" ?
Piffle. In physical terms, an increase in entropy (that's entropy, not freedom) is associated with a decrease in usefulness as order is lost. So to fit your argument MP3s should steadily transmute into white noise as they percolate through the net.
Taking a muddled metaphor and calling it a "fundamental law of nature" does not a convincing argument make.
Might it not be a good idea to release a free edition of Qt for Win32? Now that the source is GPL'ed there's nothing to prevent somebody else from building a workalike implementation layer, but using TrollTech's source would make for much cleaner development and easier upgrades to the Professional edition.
I know a lot of the /. crowd consider the whole issue of Windows ports to be beneath contempt, but there are some useful OSS projects using Qt (Doxygen springs to mind) which supply binaries for Win32 but can't be built under Win32 unless you sell off some internal organs and buy a pro license. More testing eyeballs are all very well, but it seems a shame to restrict your developer base like this.
WRT hardcore flight sims at least, I doubt that sales are actually shrinking that much. I suspect the problem is more that the target market for these games was very close to the early-adopter PC demographic; somewhat anal types who like the challenge of fiddling around with horribly complex systems.
So most of the potential market was tapped pretty early on; the explosion of PC use among Joe Public hasn't brought many new converts. Meanwhile, of course, dev costs are skyrocketing just like any other genre. From a publisher's POV this plummet in market share and ROI looks like an out-and-out loser.
Side note - am I the only one who's sick of people saying over and over again with a wistful sigh, "Remember when gameplay was all that mattered...?" Get real. There was never a Golden Age. Remember Sturgeon's Law, "90% of anything is crap". Most games sucked in the 80s too, it's just that we've forgotten those and remember the good ones. Designers then tried to make their games look as good as possible, it's just that back then "possible" didn't go very far. And designers now aren't just forgetting to check the "Good Gameplay" box in Microsoft GameWizard. Gameplay is HARD.
where C++ templates result in code bloat by producing a copy of the generic class for every concrete instance
To be fair, you can often avoid this in C++, using the same technique that you describe for GJ. Basically, where you have a collection of typed pointers, you can implement all functionality in an instantiation for void* and then subclass it with a strongly-typed casting wrapper. Stroustrup mentions this technique in CPL as an effective way to reduce bloat.
even hardware ray tracing (the number of rays you have to trace is 1st order proportional to the number of screen pixels which as I pointed out above isn't going up particularly fast - there has to be a cross-over point where this becomes usefull)
Um. Number of rays may be proportional to number of pixels (which, as you say, is fairly fixed), but the cost of evaluating intersections for each ray is proportional to the complexity of scene geometry (which is going going through the roof).
I'd agree that bandwidth constraints are important, but I don't think they're the end of the world. At the moment (on-card) bandwidth primarily limits framebuffer read/write and texture sampling; these have been major issues in the past because they were usually the bottlenecks in software 3D, but the hardware focus now is shifting more towards single-pass multitexture (which can actually reduce bandwidth requirements in some cases), per-pixel shading (which is more computation than memory access) and on-card vertex manipulation (which is a really wide-open field, and is already causing historical API models to creak a bit at the seams).
The comparison with 2D graphics is possibly misleading - 2D hit a plateau because it became "fast enough" for just about anything. I mean, once you can comfortably redraw the entire screen every frame there's nowhere much to go without branching off into Aqua-style eyecandy silliness. Maybe one day 3D will be "fast enough", but I don't see it anytime soon. There are ways around the bandwidth wall if you want to badly enough; move blending ops into RAM as some companies have done to avoid the read-modify-write round trip, or use a Talisman-style tiled architecture and parallel pipelines.
(Love the nospam penguin, btw!)
I'll be interested to see how this one does.
Consumer 3D acceleration has advanced at a phenomenal rate in the past few years, for two main reasons.
Firstly, until now everyone has been chasing SGI's taillights. SGI and OpenGL pretty much defined how to do fast 3D, so hardware and API designs have evolved toward that goal in a fairly consistent manner. (Except for a few unsuccessful oddballs like the NV-1 and D3D-RM.)
Secondly, it started off as a wide-open market with no entrenched leader. Lots of competition, leading to low prices and very fast product cycles.
This picture is starting to change, which is why I wonder whether the rate of progress is going to slow down. Firstly, consumer hardware has now caught up with SGI. SGI's "high bandwidth throughout the box" systems still win for some workstation apps, but there's no gaping chasm in speed or features any more. We're in uncharted territory now, and there's much less agreement about what the next goals should be. If every vendor starts innovating along radically different paths, apps will have a harder time using them all, and without app support the upgrade cycle is broken.
At the same time, the competition is thinning out drastically. ATI is now just about the only significant competitor to NVidia; 3Dfx is just about hanging in there but is suffering from repeated slippages and is going to have a very hard time catching up. These days NVidia is very, VERY influential in defining the direction of Direct3D, and will become more so now that they've been selected for X-Box. Remember that D3D (unlike OpenGL) has no extension mechanism, so a D3D version written to favour one vendor is a huge competitive advantage - if other vendors can't get their features exposed then they've effectively wasted a generation.
I'm a big fan of NVidia. Their hardware is superb, their drivers are excellent, they have a serious commitment to OpenGL and cross-platform support, and they contribute a lot to the graphics community in terms of research. But I'm not sure I'd like to see a total NVidia monopoly on consumer graphics. For that reason, if no other, I hope Radeon does well.