This advantage is worthless for games. Games usually have moderate geometry complexity but *very* high demands on the fillrate. Raytracing has no advantage there. Besides, today's DX10-class hardware does not distinguish between vertex and pixel shaders, which is much harder to achieve with a raytracer.
That said, a 8800 card CAN render 350 million triangles...
Raytracing has no advantage over rasterizing for opaque surfaces. Rasterizers are faster there, since their performance is not tied directly to the screen resolution. The advantages lie in refraction/reflection/shadows/translucency, which are painful to implement with rasterizers.
Thus, a hybrid seems to be the best idea. Rasterizer as default, with a special "shootray" instruction in the pixel shader.
Direct3D is more consistent, no matter what the feature is, because it was completely redesigned with release 8 and 10. The 8 redesign was necessary, the 10 understandable (but debatable). OpenGL is very elegant with primitive stuff, the kind of things the first NeHe tutorials show. But once you start entering the world of complex, modern effects, huge datasets, and today's game art, OpenGL becomes messy.
The API is inconsistent, because there are several extensions for the same goal, which tends to confuse people. Also, newer extensions follow different design paradigms than older ones. The driver gets not enough information, which is vital for optimal performance. Good example are textures; you can actually change them completely, at any time; their entire structure is mutable. This is not good for the driver, which does not know whether or not you will ever do this (and in 99% of all cases you don't). Using PBOs you can give the driver a hint (because the PBO becomes the storage space for texture, and the PBO cannot change its size), but its messy.
The solution is called OpenGL 3, and specs are available in a couple of weeks.
Management reasons:
Years ago, OpenGL was a much better choice than D3D. This got reversed in D3D8 era, because of the ARB being extremely slow and not implementing features everybody wanted (shaders, render-to-texture...). The ARB pace was also one of the main reasons Microsoft created Direct3D in the first place (remember, they were on the OpenGL bandwagon).
Now, there is just no gain in porting all those codebases using D3D9. Oh yes, OSX uses OpenGL. But OSX is an isolated platform, they have custom OpenGL extensions, and an absolutely excellent OpenGL toolchain. Nothing Windows or Linux GL developers have comes even close to this. OSX as a gaming platform is actually more interesting than Linux, because for example Blizzard supports it already, it is a platform for common users, support is far easier, and Apple is growing fast right now. Thus, osx may become a gaming market. A Linux gaming market is far less likely, and much more expensive. id and Epic ports are an unsupported bonus. And we all remember the Loki fiasco. Valve seems to be toying with the idea about supporting Linux, but thats just speculation right now (though they have the money to try it).
So the usual setup for games is this: Windows: D3D9 OSX: OpenGL Consoles: Custom
Linux is an afterthought, and maybe gets the OSX OpenGL code.
Name your source for it being an actual nuclear bomb. And the Islam thing. Schäuble said there is the danger of a dirty bomb but NOT an actual warhead. Nuclear warheads are no simple devices, they require skill to handle, otherwise it doesn't detonate, or it may even blow up while being armed etc.
As for the integration, while there are too many unintegrated ones, 100% is way too high a number.
"You do what you want, but defense of freedom is IMPORTANT in its own right, and haven't you ever asked yourself *WHY* you *NEED* Photoshop, Acrobat, etc? Don't you feel your freedom harmed by the REQUIREMENT?"
Because they are the industry standard? Because 99,99999999% of all books about photo/graphics manipulation really are about photoshop - and NOT gimp? Because Photoshop has a momentum that is absolutely impossible for GIMP to match? Maybe because all inhouse tools, documentations, courses require these tools? In case of Photoshop, maybe the entire graphics studio's displays and graphic tablets are calibrated for their customized Photoshop? Maybe there are just no opensource equivalents for programs like Maya (sorry, Blender is not nearly as powerful) and Solidworks?
I am all for civil liberties, but you have to make some compromises if you want to survive unless you find this one company that is shiny and totally pure and good. Don't forget, however, that companies usually are *very* pragmatic and will prefer Photoshop over GIMP because they get much more docs/book/tutorials for it, almost all graphics artists bring PS experience with them etc.
All those ideals won't be worth much if your job absolutely requires Photoshop, Acrobat, AutoCAD, SolidWorks, Fireworks, Maya, ColdFusion, Director etc. You know, people need an income...
My understanding of the GPL is this: if I want a program's source code to be freely available as well as any modifications to said source, I use the GPL. People are not allowed to extend my stuff without GPLing the result. They also cannot include it in their projects without GPLing the whole thing. Thats all I understand about it.
Now, GPL 2 vs. GPL 3: what exactly changes from a programmer's point of view? Googling this is hopeless, its full of blogs FUDing around, and I dont think the FSF is an unbiased source. So, anyone here with a clue?
I got attacked several times because I didn't release some libraries under the GPL, even though GPL for libraries makes absolutely _NO_ sense except in special cases (a dual license like the Qt one, or legal restrictions like in the libxvidcore case with the MPEG4 patents). I am *sick* of GPL zealots rolling eyes and calling me a retard because I don't use their holy license for everything. De Raadt is known for trolling, but so is RMS. I release programs as GPL, libraries mostly under MIT license or LGPL. Never ever got attacked by BSD guys, precisely because they don't see themselves on a moral high ground.
IIRC, the original BSD license was stripped, and the entire thing was GPLed. Which is just plain illegal. Only the original author may relicense his work.
The BSD license does *not* allow you to re-license the whole thing under GPL. BSD code must stay BSD code. And that is exactly what got ignored. ONLY THE AUTHOR HAS THE RIGHT TO RELICENSE.
No, I don't. Ok, the compiler *could* deduce the memset optimization by himself, but what about the other example I gave, the one with the cross product? How can *this* be a failure? A cross product is defined for 3d and 7d vectors _only_ (the wedge product is not the same).
And I _said_ that bit vectors have their issues. My point was that simple use from outside does not differ from bool vectors. for (iterator it = vec.begin(); it != vec.end(); ++it) { bool b = (*it); } for example; this code will read bools from the vector, and it does not matter how they are stored. I didn't have a case where the difference really matters yet in such simple operations (except for manual reads of the vector array). Do you know one?
Basic: template < typename NumericT, unsigned int Dimension > class Vec;
There are functions for adding, subtracting, normalizing, calculating dot products etc. of a Vec class.
And for Vec < NumericT, 3 > there is also a function cross(), which calculates the cross product of 3D vectors. Did Vec fail? No, of course not. It is an improvement; I *add* functionality for special cases (here, a cross product). For 4-D vectors, I could add functionality to treat the vector as a quaternion for example. You call this a failure?
JITs basically make static metaprogramming facilities obsolete (Java/JVM got a few details wrong, but the next generation or two will fix that).
I keep hearing this over and over, I'll believe it when it actually arrived.
As for performance, I write performance critical code in C++; it sounds to me like you really do not. Why? Because of statements like "An unpacked version makes absolutely no sense, since it is semantically identical." and "The point is the *possibility* of efficient, specialized versions." In fact, when performance matters, the difference between a packed and an unpacked boolean array can be big, and the difference between a possible and an actual specialized version is crucial.
Maybe I misspelled it, I meant that *access* to the container is the same; in both cases, I add a binary value, iterate over the container etc. Of course the difference lies in the performance, this is the very *point* of template specialization for std::fill. I just don't see any point in an actual std::vector container. If you access it with the public methods, it behaves just like a bitset (excluding performance). If the vector has a bool typename, then you can also use bitset-specific methods.
It is blindingly obvious that a bitset has advantages over a regular bool array. So, it should be also obvious that a specialized version of a std::fill is an improvement. (Simplifying this; there are issues with bitsets, as you said.) You say this is a sign of failure, but I do not. It is an *improvement* in a special case. The generic case works as best as possible, and the specialized one exploits... well, a special situation. If I write a generic x86 software rasterizer, and one for SSE4, then the generic one didn't "fail". The SSE4 one is just an improvement, it exploits resources otherwise unreachable.
Another example: math vectors.
Basic: template class Vec;
There are functions for adding, subtracting, normalizing, calculating dot products etc. of a Vec class.
And for Vec there is also a function cross(), which calculates the cross product of 3D vectors. Did Vec fail? No, of course not. It is an improvement; I *add* functionality for special cases (here, a cross product). For 4-D vectors, I could add functionality to treat the vector as a quaternion for example. You call this a failure?
Believe me, I have been down this road, written quite a few generic C++ libraries even before it was popular, and in the end concluded that it didn't survive a cost/benefit analysis.
So you prefer writing a list container for each type. Or a void* cast.
vector is a hand-written, specialized version of vector, so, in fact, it's an example of where genericity fails and you have to resort to overloading and manual specialization.
No, its not. From the outside, you don't have to change a single line of code for this. The outside world does not need to be aware of these internals, or any types.
Furthermore, using the vector notation instead of a distinct name like bit_vector means that (1) the code needs to pull in vector, (2) the expected unpacked vector version is unavailable even though it is what is usually needed, and (3) users don't even know what space/time tradeoff they are getting when they are using vector (and may not even be aware that this is a special case).
bit_vector is in fact available: as a typedef from vector. An unpacked version makes absolutely no sense, since it is semantically identical. Its when you want to access that as a memory block where the differences appear, but this is no longer generic. As for (3), thats what documentation is there for.
Furthermore, what makes you think you're getting efficient, specialized versions of the generic algorithms? Even if you're lucky and you get it for fill, what about all the other generic algorithms?
The point is the *possibility* of efficient, specialized versions. As said, std::fill with a vector can be reduced to a simple memset. At compile-time. No branches, no overhead, no indirections.
CommonLisp, Smalltalk, Python, Haskell, ML,...
See they are NOT in the same league. These languages offer wonderful constructs which allow generic programming even at run-time - but at a cost. I like templates because they are generic at *compile-time*, which yields a significant performance boost. I am able to switch transformation and convolution kernels in a code just by defining a different policy at compile-time, for example. Run-time generic behaviour would not only be useless, but actually harmful to performance. I am talking about real-time stuff here.
But this is another sign that C++ is actually best for system and performance-critical programming. For applications, I'd prefer Common Lisp or Objective C over C++ any day. Thus, components in C++, application in Python/CL/ObjC/Haskell sounds like a good bet. Oh, C++ is predominant in game development, too, and I don't see any sign of weakening. But then again, game dev. counts as soft realtime, with the notable exception of game logic, which actually *can* be done in another language (but that usually does not pay off because of the complexity of the glue layer). Scripting languages are on the rise (Lua comes to mind), so thats yet another trace evidence that C++ is for the components.
In any case, the basic point is still that nobody has ever shown that metaprogramming or generic programming in C++ improves programmer productivity or software quality.
Boost shows it every day. The STL shows it every day. Perfect example: std::vector becomes a bitset, and std::fill in turn fills this bitset using an optimized memset instead of setting each bit individually. These decisions are made at compile-time, where they belong. As said, look into Alexandrescu's Modern C++ Design book, and have at least a look at policy-based design. You'll never want to go back to dull templateless MFC-era C++ again. Constructing delegates is also impossible without templates (and a good example where the language gets a new feature by additional code, not adding a new language keyword).
Well, it may be the best candidate for a replacement, but I think D metaprogramming is still quite poor and limited; merely cleaning up the C++ syntax just isn't enough.
I'm curious. Give me examples of less limited metaprogramming.
Slashdot Mirror
This advantage is worthless for games. Games usually have moderate geometry complexity but *very* high demands on the fillrate. Raytracing has no advantage there. Besides, today's DX10-class hardware does not distinguish between vertex and pixel shaders, which is much harder to achieve with a raytracer.
That said, a 8800 card CAN render 350 million triangles...
Raytracing has no advantage over rasterizing for opaque surfaces. Rasterizers are faster there, since their performance is not tied directly to the screen resolution.
The advantages lie in refraction/reflection/shadows/translucency, which are painful to implement with rasterizers.
Thus, a hybrid seems to be the best idea. Rasterizer as default, with a special "shootray" instruction in the pixel shader.
Because OpenGL just sucked for a long time and nowadays there is no reason for porting existing D3D9 over to GL (~same functionality -> no gain)?
Technical reasons:
Direct3D is more consistent, no matter what the feature is, because it was completely redesigned with release 8 and 10. The 8 redesign was necessary, the 10 understandable (but debatable).
OpenGL is very elegant with primitive stuff, the kind of things the first NeHe tutorials show. But once you start entering the world of complex, modern effects, huge datasets, and today's game art, OpenGL becomes messy.
The API is inconsistent, because there are several extensions for the same goal, which tends to confuse people. Also, newer extensions follow different design paradigms than older ones. The driver gets not enough information, which is vital for optimal performance. Good example are textures; you can actually change them completely, at any time; their entire structure is mutable. This is not good for the driver, which does not know whether or not you will ever do this (and in 99% of all cases you don't). Using PBOs you can give the driver a hint (because the PBO becomes the storage space for texture, and the PBO cannot change its size), but its messy.
The solution is called OpenGL 3, and specs are available in a couple of weeks.
Management reasons:
Years ago, OpenGL was a much better choice than D3D. This got reversed in D3D8 era, because of the ARB being extremely slow and not implementing features everybody wanted (shaders, render-to-texture...). The ARB pace was also one of the main reasons Microsoft created Direct3D in the first place (remember, they were on the OpenGL bandwagon).
Now, there is just no gain in porting all those codebases using D3D9. Oh yes, OSX uses OpenGL. But OSX is an isolated platform, they have custom OpenGL extensions, and an absolutely excellent OpenGL toolchain. Nothing Windows or Linux GL developers have comes even close to this. OSX as a gaming platform is actually more interesting than Linux, because for example Blizzard supports it already, it is a platform for common users, support is far easier, and Apple is growing fast right now. Thus, osx may become a gaming market. A Linux gaming market is far less likely, and much more expensive. id and Epic ports are an unsupported bonus. And we all remember the Loki fiasco. Valve seems to be toying with the idea about supporting Linux, but thats just speculation right now (though they have the money to try it).
So the usual setup for games is this:
Windows: D3D9
OSX: OpenGL
Consoles: Custom
Linux is an afterthought, and maybe gets the OSX OpenGL code.
"Actually, I can't wait for the end of OpenGL. I want to use my card to the fullest and forcing it to support two different API's won't allow that."
Wrong. They are just frontends for the same thing.
I feel like a million chairs cried out then were silenced...
Name your source for it being an actual nuclear bomb. And the Islam thing. Schäuble said there is the danger of a dirty bomb but NOT an actual warhead. Nuclear warheads are no simple devices, they require skill to handle, otherwise it doesn't detonate, or it may even blow up while being armed etc.
As for the integration, while there are too many unintegrated ones, 100% is way too high a number.
One example says more than enough:
http://docs.python.org/lib/module-SocketServer.html
I had to google a lot of missing info to be really able to use SocketServer.
"You do what you want, but defense of freedom is IMPORTANT in its own right, and haven't you ever asked yourself *WHY* you *NEED* Photoshop, Acrobat, etc? Don't you feel your freedom harmed by the REQUIREMENT?"
Because they are the industry standard? Because 99,99999999% of all books about photo/graphics manipulation really are about photoshop - and NOT gimp? Because Photoshop has a momentum that is absolutely impossible for GIMP to match? Maybe because all inhouse tools, documentations, courses require these tools? In case of Photoshop, maybe the entire graphics studio's displays and graphic tablets are calibrated for their customized Photoshop? Maybe there are just no opensource equivalents for programs like Maya (sorry, Blender is not nearly as powerful) and Solidworks?
I am all for civil liberties, but you have to make some compromises if you want to survive unless you find this one company that is shiny and totally pure and good. Don't forget, however, that companies usually are *very* pragmatic and will prefer Photoshop over GIMP because they get much more docs/book/tutorials for it, almost all graphics artists bring PS experience with them etc.
All those ideals won't be worth much if your job absolutely requires Photoshop, Acrobat, AutoCAD, SolidWorks, Fireworks, Maya, ColdFusion, Director etc. You know, people need an income...
My understanding of the GPL is this: if I want a program's source code to be freely available as well as any modifications to said source, I use the GPL. People are not allowed to extend my stuff without GPLing the result. They also cannot include it in their projects without GPLing the whole thing. Thats all I understand about it.
Now, GPL 2 vs. GPL 3: what exactly changes from a programmer's point of view? Googling this is hopeless, its full of blogs FUDing around, and I dont think the FSF is an unbiased source. So, anyone here with a clue?
Care to reply to this? http://linux.slashdot.org/comments.pl?sid=293507&cid=20547295
Undocumented OLE blobs do not sound good. Not at all.
If people are believing such nonsense, what else are they capable of believing?
Sir, this statement made my day. Absolutely brilliant.
I got attacked several times because I didn't release some libraries under the GPL, even though GPL for libraries makes absolutely _NO_ sense except in special cases (a dual license like the Qt one, or legal restrictions like in the libxvidcore case with the MPEG4 patents). I am *sick* of GPL zealots rolling eyes and calling me a retard because I don't use their holy license for everything. De Raadt is known for trolling, but so is RMS. I release programs as GPL, libraries mostly under MIT license or LGPL. Never ever got attacked by BSD guys, precisely because they don't see themselves on a moral high ground.
IIRC, the original BSD license was stripped, and the entire thing was GPLed. Which is just plain illegal. Only the original author may relicense his work.
The BSD license does *not* allow you to re-license the whole thing under GPL. BSD code must stay BSD code. And that is exactly what got ignored. ONLY THE AUTHOR HAS THE RIGHT TO RELICENSE.
He's right on. IO has a much bigger impact.
Well, conducting many interviews calls for some streamlining, don't you think? Asking for product X is easier and faster than in-depth conversation..
Best combo: grapplers with bayonet/assault rifle.
Or: Chuck Norris with a M16.
What? They run on solar power? And its getting dark? Oh boy, I hope I have enough time left to finish this commen^%$#^%!.+^&[NO CARRIER]
No, I don't. Ok, the compiler *could* deduce the memset optimization by himself, but what about the other example I gave, the one with the cross product? How can *this* be a failure? A cross product is defined for 3d and 7d vectors _only_ (the wedge product is not the same).
And I _said_ that bit vectors have their issues. My point was that simple use from outside does not differ from bool vectors. for (iterator it = vec.begin(); it != vec.end(); ++it) { bool b = (*it); } for example; this code will read bools from the vector, and it does not matter how they are stored. I didn't have a case where the difference really matters yet in such simple operations (except for manual reads of the vector array). Do you know one?
Another example: math vectors.
Basic: template < typename NumericT, unsigned int Dimension > class Vec;
There are functions for adding, subtracting, normalizing, calculating dot products etc. of a Vec class.
And for Vec < NumericT, 3 > there is also a function cross(), which calculates the cross product of 3D vectors.
Did Vec fail? No, of course not. It is an improvement; I *add* functionality for special cases (here, a cross product). For 4-D vectors, I could add functionality to treat the vector as a quaternion for example. You call this a failure?
JITs basically make static metaprogramming facilities obsolete (Java/JVM got a few details wrong, but the next generation or two will fix that).
... well, a special situation. If I write a generic x86 software rasterizer, and one for SSE4, then the generic one didn't "fail". The SSE4 one is just an improvement, it exploits resources otherwise unreachable.
I keep hearing this over and over, I'll believe it when it actually arrived.
As for performance, I write performance critical code in C++; it sounds to me like you really do not. Why? Because of statements like "An unpacked version makes absolutely no sense, since it is semantically identical." and "The point is the *possibility* of efficient, specialized versions." In fact, when performance matters, the difference between a packed and an unpacked boolean array can be big, and the difference between a possible and an actual specialized version is crucial.
Maybe I misspelled it, I meant that *access* to the container is the same; in both cases, I add a binary value, iterate over the container etc. Of course the difference lies in the performance, this is the very *point* of template specialization for std::fill. I just don't see any point in an actual std::vector container. If you access it with the public methods, it behaves just like a bitset (excluding performance). If the vector has a bool typename, then you can also use bitset-specific methods.
It is blindingly obvious that a bitset has advantages over a regular bool array. So, it should be also obvious that a specialized version of a std::fill is an improvement. (Simplifying this; there are issues with bitsets, as you said.) You say this is a sign of failure, but I do not. It is an *improvement* in a special case. The generic case works as best as possible, and the specialized one exploits
Another example: math vectors.
Basic: template class Vec;
There are functions for adding, subtracting, normalizing, calculating dot products etc. of a Vec class.
And for Vec there is also a function cross(), which calculates the cross product of 3D vectors.
Did Vec fail? No, of course not. It is an improvement; I *add* functionality for special cases (here, a cross product). For 4-D vectors, I could add functionality to treat the vector as a quaternion for example. You call this a failure?
Believe me, I have been down this road, written quite a few generic C++ libraries even before it was popular, and in the end concluded that it didn't survive a cost/benefit analysis.
...
So you prefer writing a list container for each type. Or a void* cast.
vector is a hand-written, specialized version of vector, so, in fact, it's an example of where genericity fails and you have to resort to overloading and manual specialization.
No, its not. From the outside, you don't have to change a single line of code for this. The outside world does not need to be aware of these internals, or any types.
Furthermore, using the vector notation instead of a distinct name like bit_vector means that (1) the code needs to pull in vector, (2) the expected unpacked vector version is unavailable even though it is what is usually needed, and (3) users don't even know what space/time tradeoff they are getting when they are using vector (and may not even be aware that this is a special case).
bit_vector is in fact available: as a typedef from vector. An unpacked version makes absolutely no sense, since it is semantically identical. Its when you want to access that as a memory block where the differences appear, but this is no longer generic. As for (3), thats what documentation is there for.
Furthermore, what makes you think you're getting efficient, specialized versions of the generic algorithms? Even if you're lucky and you get it for fill, what about all the other generic algorithms?
The point is the *possibility* of efficient, specialized versions. As said, std::fill with a vector can be reduced to a simple memset. At compile-time. No branches, no overhead, no indirections.
CommonLisp, Smalltalk, Python, Haskell, ML,
See they are NOT in the same league. These languages offer wonderful constructs which allow generic programming even at run-time - but at a cost. I like templates because they are generic at *compile-time*, which yields a significant performance boost. I am able to switch transformation and convolution kernels in a code just by defining a different policy at compile-time, for example. Run-time generic behaviour would not only be useless, but actually harmful to performance. I am talking about real-time stuff here.
But this is another sign that C++ is actually best for system and performance-critical programming. For applications, I'd prefer Common Lisp or Objective C over C++ any day. Thus, components in C++, application in Python/CL/ObjC/Haskell sounds like a good bet. Oh, C++ is predominant in game development, too, and I don't see any sign of weakening. But then again, game dev. counts as soft realtime, with the notable exception of game logic, which actually *can* be done in another language (but that usually does not pay off because of the complexity of the glue layer). Scripting languages are on the rise (Lua comes to mind), so thats yet another trace evidence that C++ is for the components.
In any case, the basic point is still that nobody has ever shown that metaprogramming or generic programming in C++ improves programmer productivity or software quality.
Boost shows it every day. The STL shows it every day. Perfect example: std::vector becomes a bitset, and std::fill in turn fills this bitset using an optimized memset instead of setting each bit individually. These decisions are made at compile-time, where they belong. As said, look into Alexandrescu's Modern C++ Design book, and have at least a look at policy-based design. You'll never want to go back to dull templateless MFC-era C++ again. Constructing delegates is also impossible without templates (and a good example where the language gets a new feature by additional code, not adding a new language keyword).
Well, it may be the best candidate for a replacement, but I think D metaprogramming is still quite poor and limited; merely cleaning up the C++ syntax just isn't enough.
I'm curious. Give me examples of less limited metaprogramming.