If you want a language that can do all of the above, use C++.
Seriously, C++'s range is unmatched, even by Lisp. Its by no means a nice language, but the least of all evils. There is no other language that allows me to use a multitude of paradigms while diving down to the bare metal in the same code. If you want to replace C++, you need to write something that has its power. C++ is overly complex, yes, but not because its multi-paradigmatic, but because of the legacy support for C and the ugly template syntax.
The best part is when people say Java is the successor to C++. heh... Java's range is almost a singularity compared to C++. Or any other language.
So, people, yes! Write a successor! Really, I would love to see one that is NOT a subset of C++. The closest so far is D, but D 1.0 is barely usable. Maybe D 2.0....
Obviously you fail to understand key differences between RAII and the Java GC. The fact that you mix in try/finally only adds up to this.
RAII ensures the destructor is ran once the scope is left. The Java GC does not guarantee this. This is ok for simple memory blocks, but very bad for resources that must be freed instantly, like some locks/handles on devices. In Java, I have to use finally. In C++, RAII not only takes care of cleaning up, it also ensures exception safety.
D got it right; destructors are executed when the scope is left, but the used memory is freed up whenever the GC wants.
Additionally RAII *does* allow stuff that cannot be done with your replacements. Just try this:
mutex m;
{
scoped_lock lock(m);... do stuff... }
Exception-safe mutex locks that are automatically freed once the scope is left. Do THIS in Java.
Well, since Java has absolutely no support for true generic programming or template metaprogramming, there is zero chance of writing a library that outperforms C++ stuff like Blitz++. People are quick to mention run-time analysis, but fail to recognize C++'s true power, which are the above two. Hell, I can write domain-specific languages in C++ whose expressions are computed at compile-time and the result applied lazily at run-time.... try to do THAT in Java. Try to mimic expression templates in Java.
Java's main performance problem is that there is a lot of stuff that shouldn't be done at runtime at all. Polymorphism fully known and determined at compile-time is a good example; in C++, I can use specialization here. In Java, the VM has to figure out somehow that this one object is NEVER recast as one of its bases. Note that C++ without generic&metaprograms has the same problem, but the key difference is that in C++, I can SOLVE this.
Also, it is appaling to see how often the type system is erroneously used to do concept-checking. "Does type X fulfill the requirements of concept Y" is reduced to "is X of type Y or a derivative of Y". An example where this is bad:
struct vector { float x, y; }// used in library A
struct Vec2f { float x, y; }// used in library B
I can't simply use a vector given by library A for API calls used in B, even though the semantics are identical. In C++, this IS possible without dangerous casting.
If Java >=7 gets true generics (and not this sad joke that internally casts to Object, or the bound type in case of bound generics), then it will be much more interesting. Until then...
The main issue where C++ really is loosing the ground nowadays besides memory is that the standards body never could get their collective asses of their grounds regarding other standard libs, just look at what java provides out of the box and what is in the entire ecosystem. C++ never will have a chance to achieve that ever! The Java Standard Library has nice features, yes. Unfortunately, the language itself is complete crap; a totally featureless underpowered C++ bastard child, without C++'s disadvantages and advantages. Java has maybe 10% of C++'s power, which is a shame - they had the chance to refactor 100% of C++'s power in a language that doesn't bite you all the time.
About chance of achieving that:
I want to see something like Boost, Loki, Adobe's GIL, Blitz++ in Java.
There are ways to avoid using the delete operator, such as the standard library's auto_ptr or boost's shared_ptr, but it's often not necessary (or not wanted). To claim these types of things are necessary and should always be used is blind ignorance. No, its wise. Without them, you have to make sure your stuff is RAII-compliant and exception-safe. It is so easy to forget about delete, or to overlook a memory leak.... shared_ptr takes care of this for you, and should be preferred over auto_ptr (since unlike the latter, the former CAN be used inside an STL container).
So your sentence is wrong. It should go:
Its often not necessary (or not wanted) to use delete manually.
Because they control the GPU. You CANNOT map your typical strong functional language on a GPU. GPUs are good for a SUBSET of problems solvable by a functional language.
Photographs, sometimes. But the.hdr Format is already popular there, as are several raw formats. These are master copies, and its senseless to display them directly. Use a PNG/JPEG preview instead.
Outside these special cases, HDR has little use. PNG is perfectly ok for diagrams and other synthetic images, JPEG(2000) is perfectly ok for photograph previews and magazine scans.
A GPU excels at massively parallel tasks. Stuff like rendering, raytracing (yes! a GPU can raytrace!), DCTs,... essentially, a GPU is a stream processor that maps a function (a shader) on independent entities (pixels, or vertices). Applying a complex formula millions of times, each time with a different set of coefficients? -> GPU. GPUs fail at tasks where lots of synchronization or frequent branching is necessary. Stuff like game logic, for instance, or state machines. Your typical office application is a good example. So, GPUs are processors that operate in a very limited area. But they excel there. This is a contrast to CPUs, which are a jack of all trades.
There are a lot of easily-parallelizable problems out there, which is great...but then again, there are a lot of not-so-easily-parallelizable problems out there too. I don't think CUDA would do any better than a general-purpose CPU on the latter class of problems
Then.... use CUDA for the former and the CPU for the latter? What was your point again?:)
Oh wait do I need to explain that? Well, for example, the person you responded to said:
The reason we have so much tech development in Raster is because processing was not sufficient to do ray.
Which is absolutely true. If, when rendering with ray-tracing was first tried, computers had been as powerful as today then it is very likely that much more technology would have been developed to exploit ray-tracing. Rasterizing became popular for one simple reason: you could render faster on the available equipment.
Rasterizing became popular because you can render primary-ray-only scenarios easier and faster with it. You could get pretty far with primary rays only. Even today many scenes don't contain much secondary ray stuff. The most used secondary-ray-like effect is shadowing. Here, raytracing would definitely help. But since most of the screen isnt covered in shadows or reflective/refractive surfaces a pure raytracer just doesn't pay off.
And actually ray tracing does magically get you better image quality (for at least some definitions of "magically"). Enlighten us: WHAT exactly is improved? Shadows? Originate from secondary rays, and I already clearly stated that ray tracing is good for secondary ray effects. I want to know which part of the primary rays is magically better.
Now the idea of speeding up ray tracing by using rasterizing to generate the primary rays has been around for, oh, a good 20 years I'd say. I've written both and the calculations are different but not particularly simpler. And there is no reason why ray tracing primary rays needs to be slower than calculating by rasterizing. Rasterizing and ray tracing perform exactly the same fundamental operation: they sort the model primitives by distance from a given point.
I too have written both. Rasterizer calculations do have advantages at run-time, simply because they just linearly interpolate across triangles, while a raytracer has to perform intersection tests, which are undeniably more runtime-complex than simple lerp'ing. You also miss the fact that this simple interpolation gives you cache coherency for free, while cache coherency in raytracing is far from trivial, even with bundled rays.
Rasterizers do not sort anything, this task is done elsewhere. Read about z-buffers, painter's algorithm, self-intersection problems. They CANNOT sort anything because they only operate on the local primitive domain, e.g. they only "know" about the triangle that is currently being drawn. This lack of information about the entire geometry is one of the reasons why stuff like refractions and shadows are hard to do with a rasterizer. A raytracer has this kind of information, but doesn't sort anything either. Finding the nearest hit in a spatial hierarchy has nothing to do with sorting.
The hybrid idea is 20 years old, and still valid. Rasterizers can deliver a subset of a raytracer's output (with complicated fakes it can deliver a bigger subset). This subset happens to be what is visible 90% of the time in 3D applications like video games. Also, fake refractions/reflections can get you pretty far there. For example, HL2 uses a screen-space distortion to fake refraction. It looks good and needs little processing power. Chrome-look surfaces are easily faked by using environment mapping. Other applications do need the real deal (read: refractions/reflections using the actual physical models), but these are an entirely different topic, since the realm of spectral rendering is not far away then. Even offline renderers use fakes like this to improve rendering time. As long as it looks good the method is irrelevant.
You know that's not what I meant by edge effects. In raster based systems collision points create areas where the proper pixel to display is indeterminate. That's the basic cost of rasterization and one reason why it will always look fake. An animated picture of a wave lapping a hull is never going to look like a model of a wave lapping a hull no matter what you do to refine your raster model.
Very cryptic statement. You do mean the visual artifacts introduced by tesselating curved surfaces, for example? Unless you use parametric representations of the wave and the hull, raytracing will look "fake" as well. Again, this has nothing to do with the renderin approach, and everything with the simple fact that tesselation into triangles is prone to visible errors, especially in curved areas. Note that most, if not all real-time raytracers in existence use triangles only. Branching caused by switching primitive type is not good for performance and the cache..
Others have pointed out that photorealism isn't always the goal. That's true, but ray is also capable of doing the cartoony things without the issues you see with raster.
What issues? As said, the actual raytracing benefits all come from the secondary rays. Where do you need secondary rays in a comic/cartoon-style rendering? Even RT shadows aren't necessary for this style.
One person mentioned that John Carmack prefers raster. That may be. It also may be that John Carmack is a really smart guy and isn't going to tell you what he's up to until he releases the Carmack Ray Game Engine (R)(tm)(really cool).
Unlikely. He has revealed details about his engines in the past, and he won't change this now. Remember all this megatexture newsreel? Doom3 shading? Carmack isn't the kind of guy that likes to hide everything behind NDAs.
One major benefit of ray is that it's embarassingly parallel. Performance scales linearly across multiple cores. Each core does not have to be very fast -- its load just has to be no more rays than it can handle in each refresh cycle. Multiplying cores does not increase latency.
Rasterization too is embarassingly parallel, no wins here. Check out this presentation from Tim Sweeney if you don't believe me. A 8800 GTX uses 128 shaders at the same time. In addition, rasterization is MUCH easier to parallelize because it involves no spatial data structure necessary for ray-geometry intersection tests. In fact, these tests aren't required at all - all a rasterizer has to do is linear interpolation of data across triangles projected on screen. This is what makes rasterization trivially cache friendly. Cache coherence is a major problem with raytracing and one of the showstoppers for real-time RT - because caching is extremely important for the scene and shading complexity we deal with nowadays.
Current raster models require maximum clocks for each GPU for good results. This is a problem because for a given GPU architecture power dissipation as a function of clock speed is definitely non-linear. This means that at some point your triple core per card, 3 card GPU system is going to require 1200 Watts at least and all of the requisite cooling, noise and physical volume required to serve that issue. OTOH, 1024 250mW cores only take 250 Watts.
And let's not forget about the fact that there might be other uses for a system with 1024 microcores that would help drive up demand and help hit the economy of scale metrics that make such a thing profitable.
AGAIN: GPUs ARE massively parallelized. Do you *really* think clock speed is everything on a GPU? Also, 1024 microcores will be useless for 98% of a typical PC's tasks. Synchronization issues will kill off the use of so many cores for gaining performance. Besides, a RT card would require high clock frequencies as wel
Raytracing doesnt magically get you better image quality. EXCEPT for shadows, the results look just like rasterization. As usual, people mix up raytracing with path tracing, photon mapping, radiosity, and other GI algorithms. Note: GI can be applied to rasterization as well.
So, which "benefits" are left? Refraction/reflection, haze, and any kind of ray distortion - SECONDARY ray effects. Primary rays can be fully modeled with rasterization, which gives you much better performance because of the trivial cache coherency and simpler calculations. (In a sense, rasterization can be seen as a cleverly optimized primary-ray-pass). This is why hybrid renderers make PERFECT sense. Yes, I know ray bundles, they are hard to get right, and again: for primary rays, raytracing makes no sense.
"Suspension of disbelief" is necessary with raytracing too. You confuse the rendering technique with lighting models, animation quality and so on. "edge effects" is laughable, aliasing WILL occur with raytracing as well unless you shoot multiple rays per pixel (and guess what... rasterizers commonly HAVE MSAA).
Jeez, when will people stop thinking all this BS about raytracing? As if it were a magical thingie capable of miracously enhancing your image quality....
Raytracing has its place - as an ADDITION to a rasterizer, to ease implementation of the secondary ray effects (which are hard to simulate with pure rasterization). This is the future.
Poor to mediocre hardware, buggy drivers, patent-trolling, not only giving shit about customers, but punishing them for trying to improve the situation. Their real sin was to destroy Ensoniq and Aureal, which were lightyears ahead both in technology and customer care. Creative's death is inevitable, since AC97 onboard chips are killing their marketshare. Unfortunately, this means they will mutate into yet another patent troll that produces absolutely nothing. They have killed progress in PC audio, will continue to kill it.
Well, there is some wisdom in this setup, however the current stacks are not built for this. GUIs belong in containers like XML or JSON, the actual program should only handle events (button clicked, dialog box closed, text entered etc.) Its the good old model view controller pattern, with the program being the controller.
As said, the current stack is absolutely INappropiate for this kind of usage. HTML just wasn't built for this kind of operation; XUL/XAML are more suited for this. The whole AJAX thing uses the wrong technologies for the job, the HTML/Javascript/XML stack isn't designed for dealing with things like latency, clear MVC separation (note that parts of the controller and model are mixed up with the view in AJAX), standard widgets, accessibility, standardization etc.
So while scripted GUIs are a very good idea (since they allow RAD without code generators, bring you skinning for free, and allow the GUI designer to work independently of the coder), AJAX is only a lukewarm implementation.
This is just a customized GCC. Lock-in means you cannot get out by any means except expensive reverse-engineering (not required here, since Apple's GCC code is fully available). Also, no patents apply (otherwise the GPL could not be used), so there is no IP blocker either. It is by all means just a customized version of some opensource software. ARM does this all the time, for example.
Note though that the GPL is specifically designed to prevent Embrace&Extend. They cannot take, say, gcc, and develop propietary closed-source extensions on top.Their only way of applying lock-in is by using propietary formats and protocols - which require apps to be written from scratch. So, nothing new on the assimilation front.
These were the only joysticks that could beat the Atari controllers. These things were made of inexplicabium. I used it for more than a decade, and it still works perfectly (and, I was NOT gentle). Now THATs engineering.
You were taught Java 10 years ago? This does not necessarily mean that Java is a good language, only that you were taught this language, nothing more. Did you learn all or most the things I mentioned with Java? No? Then, did you learn any other language that supports them? Were you taught these things at all? These are the really important questions, because too often, both are answered with "no".
Java is used everywhere - so? This only proves that the industry is pushing Java, not that Java is a good language. It is a myth that the industry uses the best tool available. Actually, it is a complex sequence of hype, marketing, and politics. There are countless examples where the worse product won over the better one. In the case of Java, the masses of mediocre programmers are another reason; they are cheap, expendable, and quick to produce in the Java-codemonkey-factories that universities have become. The fact that 99% of the produced code is unnecessary and/or lousy is silently accepted.
A lot of useful work has been accomplished with it. Yes. The same can be said about Visual Basic, Cobol, Mumps,... it still does not elevate the language.
True generics are one of C++ main strengths. Lambdas are somewhat supported, in a very limited sense via boost.lambda, and as a language element in C++0x, though it does have issues since full support for closures is not possible because of the lifespan of variables. The C++ template metaprogramming language is pure functional. Coroutines are possible with ugly hacks, but these are generally discouraged.
But my point is that the knowledge of all these things expands your abilities and mental flexibility. You tend to see the problem from more (and different) perspectives. And I agree, Common Lisp/Scheme is best for teaching these things (although the syntax may be scary for starters). That's why I favor Lisp as starting language, NOT Java.
Imagine teaching closures, coroutines, true generics, conditions, pure functional coding, arrows, lambdas, etc. in Java.
See? Java has very limited expressiveness. People are taught what's hot today. Tomorrow, different languages are hot, with different paradigma. Or, they get a job where other paradigma are important. Now, see how hard the people have to try to adapt.
If all you ever got taught was to use a hammer for everything, you will have a hard time adapting to a scalpel.
Slashdot Mirror
If you want a language that can do all of the above, use C++.
Seriously, C++'s range is unmatched, even by Lisp. Its by no means a nice language, but the least of all evils. There is no other language that allows me to use a multitude of paradigms while diving down to the bare metal in the same code. If you want to replace C++, you need to write something that has its power. C++ is overly complex, yes, but not because its multi-paradigmatic, but because of the legacy support for C and the ugly template syntax.
The best part is when people say Java is the successor to C++. heh... Java's range is almost a singularity compared to C++. Or any other language.
So, people, yes! Write a successor! Really, I would love to see one that is NOT a subset of C++. The closest so far is D, but D 1.0 is barely usable. Maybe D 2.0....
Obviously you fail to understand key differences between RAII and the Java GC. The fact that you mix in try/finally only adds up to this.
... do stuff ...
RAII ensures the destructor is ran once the scope is left. The Java GC does not guarantee this. This is ok for simple memory blocks, but very bad for resources that must be freed instantly, like some locks/handles on devices. In Java, I have to use finally. In C++, RAII not only takes care of cleaning up, it also ensures exception safety.
D got it right; destructors are executed when the scope is left, but the used memory is freed up whenever the GC wants.
Additionally RAII *does* allow stuff that cannot be done with your replacements. Just try this:
mutex m;
{
scoped_lock lock(m);
}
Exception-safe mutex locks that are automatically freed once the scope is left. Do THIS in Java.
Also, finalizers are amusing stuff: http://www-128.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
Well, since Java has absolutely no support for true generic programming or template metaprogramming, there is zero chance of writing a library that outperforms C++ stuff like Blitz++. People are quick to mention run-time analysis, but fail to recognize C++'s true power, which are the above two. Hell, I can write domain-specific languages in C++ whose expressions are computed at compile-time and the result applied lazily at run-time.... try to do THAT in Java. Try to mimic expression templates in Java.
// used in library A
// used in library B
Java's main performance problem is that there is a lot of stuff that shouldn't be done at runtime at all. Polymorphism fully known and determined at compile-time is a good example; in C++, I can use specialization here. In Java, the VM has to figure out somehow that this one object is NEVER recast as one of its bases. Note that C++ without generic&metaprograms has the same problem, but the key difference is that in C++, I can SOLVE this.
Also, it is appaling to see how often the type system is erroneously used to do concept-checking. "Does type X fulfill the requirements of concept Y" is reduced to "is X of type Y or a derivative of Y". An example where this is bad:
struct vector { float x, y; }
struct Vec2f { float x, y; }
I can't simply use a vector given by library A for API calls used in B, even though the semantics are identical. In C++, this IS possible without dangerous casting.
If Java >=7 gets true generics (and not this sad joke that internally casts to Object, or the bound type in case of bound generics), then it will be much more interesting. Until then...
About chance of achieving that:
I want to see something like Boost, Loki, Adobe's GIL, Blitz++ in Java.
So your sentence is wrong. It should go:
Its often not necessary (or not wanted) to use delete manually.
CUDA is weird. CTM too.
Why?
Because they control the GPU. You CANNOT map your typical strong functional language on a GPU. GPUs are good for a SUBSET of problems solvable by a functional language.
I recommend to watch this one: http://en.wikipedia.org/wiki/Gnash
Photographs, sometimes. But the .hdr Format is already popular there, as are several raw formats. These are master copies, and its senseless to display them directly. Use a PNG/JPEG preview instead.
Outside these special cases, HDR has little use. PNG is perfectly ok for diagrams and other synthetic images, JPEG(2000) is perfectly ok for photograph previews and magazine scans.
OpenEXR isnt intended for use in the web. Its a HDR format for CG, commonly used for light probes among others. But for the web?
A GPU excels at massively parallel tasks. Stuff like rendering, raytracing (yes! a GPU can raytrace!), DCTs, ... essentially, a GPU is a stream processor that maps a function (a shader) on independent entities (pixels, or vertices).
Applying a complex formula millions of times, each time with a different set of coefficients? -> GPU.
GPUs fail at tasks where lots of synchronization or frequent branching is necessary. Stuff like game logic, for instance, or state machines. Your typical office application is a good example.
So, GPUs are processors that operate in a very limited area. But they excel there. This is a contrast to CPUs, which are a jack of all trades.
Then .... use CUDA for the former and the CPU for the latter? What was your point again? :)
Wrong.
Oh wait do I need to explain that? Well, for example, the person you responded to said:
The reason we have so much tech development in Raster is because processing was not sufficient to do ray.
Which is absolutely true. If, when rendering with ray-tracing was first tried, computers had been as powerful as today then it is very likely that much more technology would have been developed to exploit ray-tracing. Rasterizing became popular for one simple reason: you could render faster on the available equipment.
Rasterizing became popular because you can render primary-ray-only scenarios easier and faster with it. You could get pretty far with primary rays only. Even today many scenes don't contain much secondary ray stuff. The most used secondary-ray-like effect is shadowing. Here, raytracing would definitely help. But since most of the screen isnt covered in shadows or reflective/refractive surfaces a pure raytracer just doesn't pay off.
And actually ray tracing does magically get you better image quality (for at least some definitions of "magically"). Enlighten us: WHAT exactly is improved? Shadows? Originate from secondary rays, and I already clearly stated that ray tracing is good for secondary ray effects. I want to know which part of the primary rays is magically better. Now the idea of speeding up ray tracing by using rasterizing to generate the primary rays has been around for, oh, a good 20 years I'd say. I've written both and the calculations are different but not particularly simpler. And there is no reason why ray tracing primary rays needs to be slower than calculating by rasterizing. Rasterizing and ray tracing perform exactly the same fundamental operation: they sort the model primitives by distance from a given point.I too have written both. Rasterizer calculations do have advantages at run-time, simply because they just linearly interpolate across triangles, while a raytracer has to perform intersection tests, which are undeniably more runtime-complex than simple lerp'ing. You also miss the fact that this simple interpolation gives you cache coherency for free, while cache coherency in raytracing is far from trivial, even with bundled rays.
Rasterizers do not sort anything, this task is done elsewhere. Read about z-buffers, painter's algorithm, self-intersection problems. They CANNOT sort anything because they only operate on the local primitive domain, e.g. they only "know" about the triangle that is currently being drawn. This lack of information about the entire geometry is one of the reasons why stuff like refractions and shadows are hard to do with a rasterizer. A raytracer has this kind of information, but doesn't sort anything either. Finding the nearest hit in a spatial hierarchy has nothing to do with sorting.
The hybrid idea is 20 years old, and still valid. Rasterizers can deliver a subset of a raytracer's output (with complicated fakes it can deliver a bigger subset). This subset happens to be what is visible 90% of the time in 3D applications like video games. Also, fake refractions/reflections can get you pretty far there. For example, HL2 uses a screen-space distortion to fake refraction. It looks good and needs little processing power. Chrome-look surfaces are easily faked by using environment mapping. Other applications do need the real deal (read: refractions/reflections using the actual physical models), but these are an entirely different topic, since the realm of spectral rendering is not far away then. Even offline renderers use fakes like this to improve rendering time. As long as it looks good the method is irrelevant.
You know that's not what I meant by edge effects. In raster based systems collision points create areas where the proper pixel to display is indeterminate. That's the basic cost of rasterization and one reason why it will always look fake. An animated picture of a wave lapping a hull is never going to look like a model of a wave lapping a hull no matter what you do to refine your raster model.
Very cryptic statement. You do mean the visual artifacts introduced by tesselating curved surfaces, for example? Unless you use parametric representations of the wave and the hull, raytracing will look "fake" as well. Again, this has nothing to do with the renderin approach, and everything with the simple fact that tesselation into triangles is prone to visible errors, especially in curved areas. Note that most, if not all real-time raytracers in existence use triangles only. Branching caused by switching primitive type is not good for performance and the cache..
Others have pointed out that photorealism isn't always the goal. That's true, but ray is also capable of doing the cartoony things without the issues you see with raster.
What issues? As said, the actual raytracing benefits all come from the secondary rays. Where do you need secondary rays in a comic/cartoon-style rendering? Even RT shadows aren't necessary for this style.
One person mentioned that John Carmack prefers raster. That may be. It also may be that John Carmack is a really smart guy and isn't going to tell you what he's up to until he releases the Carmack Ray Game Engine (R)(tm)(really cool).
Unlikely. He has revealed details about his engines in the past, and he won't change this now. Remember all this megatexture newsreel? Doom3 shading? Carmack isn't the kind of guy that likes to hide everything behind NDAs.
One major benefit of ray is that it's embarassingly parallel. Performance scales linearly across multiple cores. Each core does not have to be very fast -- its load just has to be no more rays than it can handle in each refresh cycle. Multiplying cores does not increase latency.
Rasterization too is embarassingly parallel, no wins here. Check out this presentation from Tim Sweeney if you don't believe me. A 8800 GTX uses 128 shaders at the same time. In addition, rasterization is MUCH easier to parallelize because it involves no spatial data structure necessary for ray-geometry intersection tests. In fact, these tests aren't required at all - all a rasterizer has to do is linear interpolation of data across triangles projected on screen. This is what makes rasterization trivially cache friendly. Cache coherence is a major problem with raytracing and one of the showstoppers for real-time RT - because caching is extremely important for the scene and shading complexity we deal with nowadays.
Current raster models require maximum clocks for each GPU for good results. This is a problem because for a given GPU architecture power dissipation as a function of clock speed is definitely non-linear. This means that at some point your triple core per card, 3 card GPU system is going to require 1200 Watts at least and all of the requisite cooling, noise and physical volume required to serve that issue. OTOH, 1024 250mW cores only take 250 Watts.
And let's not forget about the fact that there might be other uses for a system with 1024 microcores that would help drive up demand and help hit the economy of scale metrics that make such a thing profitable.
AGAIN: GPUs ARE massively parallelized. Do you *really* think clock speed is everything on a GPU? Also, 1024 microcores will be useless for 98% of a typical PC's tasks. Synchronization issues will kill off the use of so many cores for gaining performance. Besides, a RT card would require high clock frequencies as wel
Wrong. All of it.
Raytracing doesnt magically get you better image quality. EXCEPT for shadows, the results look just like rasterization. As usual, people mix up raytracing with path tracing, photon mapping, radiosity, and other GI algorithms. Note: GI can be applied to rasterization as well.
So, which "benefits" are left? Refraction/reflection, haze, and any kind of ray distortion - SECONDARY ray effects. Primary rays can be fully modeled with rasterization, which gives you much better performance because of the trivial cache coherency and simpler calculations. (In a sense, rasterization can be seen as a cleverly optimized primary-ray-pass). This is why hybrid renderers make PERFECT sense. Yes, I know ray bundles, they are hard to get right, and again: for primary rays, raytracing makes no sense.
"Suspension of disbelief" is necessary with raytracing too. You confuse the rendering technique with lighting models, animation quality and so on. "edge effects" is laughable, aliasing WILL occur with raytracing as well unless you shoot multiple rays per pixel (and guess what... rasterizers commonly HAVE MSAA).
Jeez, when will people stop thinking all this BS about raytracing? As if it were a magical thingie capable of miracously enhancing your image quality....
Raytracing has its place - as an ADDITION to a rasterizer, to ease implementation of the secondary ray effects (which are hard to simulate with pure rasterization). This is the future.
Is George Romero making a new movie?
Poor to mediocre hardware, buggy drivers, patent-trolling, not only giving shit about customers, but punishing them for trying to improve the situation. Their real sin was to destroy Ensoniq and Aureal, which were lightyears ahead both in technology and customer care. Creative's death is inevitable, since AC97 onboard chips are killing their marketshare. Unfortunately, this means they will mutate into yet another patent troll that produces absolutely nothing. They have killed progress in PC audio, will continue to kill it.
Please, Creative, just vanish.
Well, there is some wisdom in this setup, however the current stacks are not built for this. GUIs belong in containers like XML or JSON, the actual program should only handle events (button clicked, dialog box closed, text entered etc.) Its the good old model view controller pattern, with the program being the controller.
As said, the current stack is absolutely INappropiate for this kind of usage. HTML just wasn't built for this kind of operation; XUL/XAML are more suited for this. The whole AJAX thing uses the wrong technologies for the job, the HTML/Javascript/XML stack isn't designed for dealing with things like latency, clear MVC separation (note that parts of the controller and model are mixed up with the view in AJAX), standard widgets, accessibility, standardization etc.
So while scripted GUIs are a very good idea (since they allow RAD without code generators, bring you skinning for free, and allow the GUI designer to work independently of the coder), AJAX is only a lukewarm implementation.
if the Dr.'s kids were addited to WoW.
This is just a customized GCC. Lock-in means you cannot get out by any means except expensive reverse-engineering (not required here, since Apple's GCC code is fully available). Also, no patents apply (otherwise the GPL could not be used), so there is no IP blocker either. It is by all means just a customized version of some opensource software. ARM does this all the time, for example.
Note though that the GPL is specifically designed to prevent Embrace&Extend. They cannot take, say, gcc, and develop propietary closed-source extensions on top.Their only way of applying lock-in is by using propietary formats and protocols - which require apps to be written from scratch. So, nothing new on the assimilation front.
Game Boy gaming maniacs of the 90s? Washing hands?
I smell some oxymorons here.
These were the only joysticks that could beat the Atari controllers. These things were made of inexplicabium. I used it for more than a decade, and it still works perfectly (and, I was NOT gentle). Now THATs engineering.
You were taught Java 10 years ago? This does not necessarily mean that Java is a good language, only that you were taught this language, nothing more.
... it still does not elevate the language.
Did you learn all or most the things I mentioned with Java? No? Then, did you learn any other language that supports them? Were you taught these things at all? These are the really important questions, because too often, both are answered with "no".
Java is used everywhere - so? This only proves that the industry is pushing Java, not that Java is a good language. It is a myth that the industry uses the best tool available. Actually, it is a complex sequence of hype, marketing, and politics. There are countless examples where the worse product won over the better one. In the case of Java, the masses of mediocre programmers are another reason; they are cheap, expendable, and quick to produce in the Java-codemonkey-factories that universities have become. The fact that 99% of the produced code is unnecessary and/or lousy is silently accepted.
A lot of useful work has been accomplished with it. Yes. The same can be said about Visual Basic, Cobol, Mumps,
True generics are one of C++ main strengths. Lambdas are somewhat supported, in a very limited sense via boost.lambda, and as a language element in C++0x, though it does have issues since full support for closures is not possible because of the lifespan of variables. The C++ template metaprogramming language is pure functional. Coroutines are possible with ugly hacks, but these are generally discouraged.
But my point is that the knowledge of all these things expands your abilities and mental flexibility. You tend to see the problem from more (and different) perspectives. And I agree, Common Lisp/Scheme is best for teaching these things (although the syntax may be scary for starters). That's why I favor Lisp as starting language, NOT Java.
Imagine teaching closures, coroutines, true generics, conditions, pure functional coding, arrows, lambdas, etc. in Java.
See? Java has very limited expressiveness. People are taught what's hot today. Tomorrow, different languages are hot, with different paradigma. Or, they get a job where other paradigma are important. Now, see how hard the people have to try to adapt.
If all you ever got taught was to use a hammer for everything, you will have a hard time adapting to a scalpel.