How can Clock Tower be missing here? Particularly the very first one running on SNES, which still gives me the creeps, even when watching youtube recordings of its gameplay (example: http://www.youtube.com/watch?v=n7N8Q69--Ws). This game is VERY VERY scary.
I doubt it. Hypertext is the very core of HTML. Its even in the name: HYPERTEXT markup language. For example, a proper webapp description language would include layouts, and a standard set of widgets that is NOT used like a form. And guess what stuff like XUL and XAML does. Guess why they even *exist*....
The Web does not disagree with me. What we have today is hypertext distorted to behave like an application. If anything, the web proves it everyday, when heaps of constructs are necessary to twist HTML into a webapp form. For example, what sense does a back button make in _web apps_? Why isn't there a proper solution for correct asynchronous communication (Ajax is only browser->server, for server->browser you need (long) polling or comet)? Etc. A web designed for webapps would look differently.
Agreed. The web is not a place for applications. HTML is designed for hyper_text_.
A "webapp browser" would essentially be the view and one half of the controller in the MVC pattern. An interesting idea would be to have the browser as an environment for Adobe Adam & Eve scripts: http://lambda-the-ultimate.org/node/563 .
Whats the problem with JavaScript? I have written JS code with >20k lines already, and it was quite ok. Among the things that irritate me is this "var" nonsense (declaring a variable without var puts it in the global namespace!), but other than that, it was fine. Also, you are wrong, JS has real objects. And, weak typing can be a very powerful tool if used properly. Note that Python has weak typing too...
All of these are just workarounds for the very problems that NAT causes. In other words, with ipv6, I don't need virtual hosting, or strange batch files that open up ports. Instead, "it just works".
C obsolete and pointless? With the exception of mobile phones (which is a rigidly locked-down market anyway), virtually any embedded device you can find has soft/firmware written in C or C++. And, the embedded devices market is vastly greater than the PC or server one. So, tell the professors to get a clue.
Twinview works reasonably well ONLY for monitors with the same resolutions. If the resolutions differ - it works like pure shit.
I am running one monitor at 1680x1050 and another one at 1280x1024. I have yet to experience any of these problems you mention. And I do run games. I even coded myself a X11-OpenGL-library because SDL, GLFW etc. do not support multiple contexts and multiple monitors; for example, I can have two contexts, one for each monitor, both at fullscreen, and render to both with direct rendering. Compiz also works for me.
You never limited your statement to OpenGL. You also said that it was GENERALLY much better.
Okay, my error. I meant it is *mostly* about OpenGL. For a non-OpenGL example, when I switch to a text console and then back to X11, fglrx freezes the kernel on my laptop with a 9600 radeon. This is an ancient card, and one might think that bugs as major as this one have been ironed out by now, but no. I have never experienced something similar with nvidia. With nvidia drivers, it "just worked". Always. Complete with DRI and all. With fglrx, I am lucky to get it to work at all. Then, I have to spend more time trying to get DRI to work. I thought this is just true for the old 9600 , but imagine my surprise when very similar issues appeared with the HD 2600 I use at work.
And I've just proven that untrue. Xrandr 1.2 is included in the newest X.org.
Xrandr is not part of the OpenGL registry. Read again what I said:
New standardized feature X is added to the registry.
Second, I have twinview with direct rendering on both screens. While it is not Randr, it works reasonably well. Nvidia itself states in their driver FAQ that they are waiting until Randr is fully freezed before development starts.
Their CUDA push has zero to do with GL3. As I mentioned before, nvidia ALREADY supports OpenGL3 in a beta driver. So they beat ATI once again. I really hope AMD forces ATI to beef up its driver development...
In addition, one just has to look at the OpenGL extension registry, and note the authors. MANY extensions (and most cutting-edge ones) came from nvidia.
Guess what CUDA and Stream have been designed for? Yes: for programming the hardware. What you suggest is pure insanity. NEVER EVER touch hardware directly from an userland app. And once you start writing a kernel module, you end up with something like CUDA/Stream anyway.
I am a coder, and quite frankly I couldn't care less about nvidia drivers being closed source. They are MUCH better than the ATI ones, especially in the OpenGL department. nvidia whipped up a beta GL 3.0 driver in less than a month since GL3 specs were released. ATI? Nope. New standardized feature X is added to the registry. nvidia adds it pretty quickly; ATI adds it months, even years later. nvidia drivers are also pretty robust; I can bombard them with faulty OpenGL code, and they remain standing. With ATI's fglrx, even CORRECT code can cause malfunctioning.
THESE are the things I care about. Not the license.
Not in the embedded devices world. It was tiny, but now more and more of them are using Linux kernels. I've seen it often on internet radios, music players, STBs, even picture frames. And not just on 10% of them - I'd say more like 40%.
But "not branching" may turn out to be more expensive than the branching overhead. In fact, this is often the case. The costs you saved by not branching are spent on hacks inside the stable branch to have the experimental bits only optionally enabled. (In C, its a sea of #ifdef/#endifs.)
First, all of these methods are hacks. Putting experimental, disabled code in your stable release is a really ugly hack.
Second, sometimes you cannot start small. If you replace an entire subsystem, you want to keep the current one until the new one is stable. A good example is a new renderer; software X has been using its old OpenGL renderer, but it just can't handle the ever increasing datasets anymore. So you write a new renderer Y, which CAN handle large sets. It is not possible to start small here; you cannot just develop "a little bit" of Y, neither can (and should) you introduce small changes in X, because Y is fundamentally different. In git, I create a branch for Y. It is especially useful in cases where components (like the renderer here) cannot be plug-ins, but need to be hooked in the main program. git merge vs. re-enabling all previously dormant code parts...
And what about experimental code? Your solution would be to keep this experimental code locally on the HD until its either stable or determined to be useless, yes?
In git, I create a branch, put the experimental stuff in, if it turns out to be useful, I merge it with the head branch and remove the branch, if its useless, I just delete the branch. Meanwhile, I can continue developing and maintaining the stable branch. Try this with svn...
Actually, its not. OpenGL is on par with Direct3D. It the API that sucks, because the core API no longer accurately reflects modern hardware, and everything thats nice is in new 2.1 features + extensions, which are progressing into an object model similar to Longs Peak. Therefore, right now OpenGL is a mixed bag - state machine style initialization for textures, object model style initialization for pixel/vertex/framebuffer objects & shaders.
Curved Surfaces are harder to control, require more logic in the chip (the triangle can be rasterized just by using 3 half spaces), are a royal pain for collision detection, look awful for anything that does not fit nicely as a curved surface, and can be approximated nicely using many triangles anyway. This tire is just badly modeled, thats all. Oh, and putting multiple types of primitives in the hardware is insane, nobody will do it. Even wireframe edges are simulated using thin triangles in typical GPUs.
If anything, I'd pursue research into cheap HW acceleration of voxel graphics. I guess the main obstacle here is memory, since voxels can get big pretty quickly...
Your "afraid to pursue any technologies that might make their existing technologies obsolete" statement is rubbish. You know this thing called "R&D"? This is where companies come up with new technologies that haven't been proven in the marketplace. Expect nvidia R&D for a hybrid renderer there.
And, AGAIN: raytracing is NOT a shiny new hammer for rendering. It CANNOT beat rasterization for surfaces that do not exhibit secondary-ray features (like any opaque, non-reflective surface, which usually make up ~60-70% of game scenes). This is why a hybrid renderer is more logical: ray tracing only pays off for secondary-ray effects like refraction or shadows. In fact, most papers that try to accelerate ray tracing include a special path for such surfaces, where standard rasterization is used. Its only Intel who's blabbering about pure raytracing.
Well, you might want to tell Adobe that. Hint: they do use this modern C++ you abhor. You did use Photoshop, right?
Also, your conclusion is flawed. Since when does the best solution automatically win? The one which gets strongly pushed, hyped, marketed etc. is the one that wins, NOT the best one.
Instead of that they have been built using "toyish" (hey, they don't have things such as multiple inheritance etc what the C++ nerds always whine about) languages that actually lack most of the "nice" things of C++.
Yes, because 20 mediocre programmer code monkeys are cheaper than 4 top-class developers. Java is primitive, thus easy to grasp. C++ is not, even without the hideous syntax that artificially increases the difficulty. Its simple: if one language has more features and expressiveness than another, the latter is better suited for the average code monkey. Also, code monkeys are expendable, top-class developers are not. A manager's dream.
except that it takes 10 times more time to develop in C++
Now we have to be precise here. Remove enough bits of the Java standard library to equal C++'s in size, THEN judge again. People keep comparing plain C++ with a JDK-doped, Eclipse/IDEAI-enhanced Java. This brings us to Java's REAL advantage: its toolchain and SDK. Both are very good. Without them, the language is worthless.
Slashdot Mirror
Don't trust anybody for anything that matters. Except a very carefully selected few.
How can Clock Tower be missing here? Particularly the very first one running on SNES, which still gives me the creeps, even when watching youtube recordings of its gameplay (example: http://www.youtube.com/watch?v=n7N8Q69--Ws). This game is VERY VERY scary.
I doubt it. Hypertext is the very core of HTML. Its even in the name: HYPERTEXT markup language. For example, a proper webapp description language would include layouts, and a standard set of widgets that is NOT used like a form. And guess what stuff like XUL and XAML does. Guess why they even *exist*....
The Web does not disagree with me. What we have today is hypertext distorted to behave like an application. If anything, the web proves it everyday, when heaps of constructs are necessary to twist HTML into a webapp form. For example, what sense does a back button make in _web apps_? Why isn't there a proper solution for correct asynchronous communication (Ajax is only browser->server, for server->browser you need (long) polling or comet)? Etc. A web designed for webapps would look differently.
Hmm, right, confused this with dynamic typing.
Agreed. The web is not a place for applications. HTML is designed for hyper_text_.
A "webapp browser" would essentially be the view and one half of the controller in the MVC pattern. An interesting idea would be to have the browser as an environment for Adobe Adam & Eve scripts: http://lambda-the-ultimate.org/node/563 .
Whats the problem with JavaScript? I have written JS code with >20k lines already, and it was quite ok. Among the things that irritate me is this "var" nonsense (declaring a variable without var puts it in the global namespace!), but other than that, it was fine. Also, you are wrong, JS has real objects. And, weak typing can be a very powerful tool if used properly. Note that Python has weak typing too...
(If you want speedy, write in C/C++, Java, or something)
Or OCaml, Haskell, Lua.
All of these are just workarounds for the very problems that NAT causes. In other words, with ipv6, I don't need virtual hosting, or strange batch files that open up ports. Instead, "it just works".
C obsolete and pointless?
With the exception of mobile phones (which is a rigidly locked-down market anyway), virtually any embedded device you can find has soft/firmware written in C or C++. And, the embedded devices market is vastly greater than the PC or server one. So, tell the professors to get a clue.
Nah, it would melt the internet tubes.
Twinview works reasonably well ONLY for monitors with the same resolutions. If the resolutions differ - it works like pure shit.
I am running one monitor at 1680x1050 and another one at 1280x1024. I have yet to experience any of these problems you mention. And I do run games. I even coded myself a X11-OpenGL-library because SDL, GLFW etc. do not support multiple contexts and multiple monitors; for example, I can have two contexts, one for each monitor, both at fullscreen, and render to both with direct rendering. Compiz also works for me.
You never limited your statement to OpenGL. You also said that it was GENERALLY much better.
Okay, my error. I meant it is *mostly* about OpenGL. For a non-OpenGL example, when I switch to a text console and then back to X11, fglrx freezes the kernel on my laptop with a 9600 radeon. This is an ancient card, and one might think that bugs as major as this one have been ironed out by now, but no. I have never experienced something similar with nvidia. With nvidia drivers, it "just worked". Always. Complete with DRI and all. With fglrx, I am lucky to get it to work at all. Then, I have to spend more time trying to get DRI to work. I thought this is just true for the old 9600 , but imagine my surprise when very similar issues appeared with the HD 2600 I use at work.
And I've just proven that untrue. Xrandr 1.2 is included in the newest X.org.
Xrandr is not part of the OpenGL registry. Read again what I said:
New standardized feature X is added to the registry .
First, this is about OpenGL.
Second, I have twinview with direct rendering on both screens. While it is not Randr, it works reasonably well. Nvidia itself states in their driver FAQ that they are waiting until Randr is fully freezed before development starts.
Their CUDA push has zero to do with GL3. As I mentioned before, nvidia ALREADY supports OpenGL3 in a beta driver. So they beat ATI once again. I really hope AMD forces ATI to beef up its driver development...
In addition, one just has to look at the OpenGL extension registry, and note the authors. MANY extensions (and most cutting-edge ones) came from nvidia.
meaning you can code directly the hardware
Guess what CUDA and Stream have been designed for? Yes: for programming the hardware. What you suggest is pure insanity. NEVER EVER touch hardware directly from an userland app. And once you start writing a kernel module, you end up with something like CUDA/Stream anyway.
I am a coder, and quite frankly I couldn't care less about nvidia drivers being closed source. They are MUCH better than the ATI ones, especially in the OpenGL department. nvidia whipped up a beta GL 3.0 driver in less than a month since GL3 specs were released. ATI? Nope. New standardized feature X is added to the registry. nvidia adds it pretty quickly; ATI adds it months, even years later. nvidia drivers are also pretty robust; I can bombard them with faulty OpenGL code, and they remain standing. With ATI's fglrx, even CORRECT code can cause malfunctioning.
THESE are the things I care about. Not the license.
Linux is a tiny market
Not in the embedded devices world. It was tiny, but now more and more of them are using Linux kernels. I've seen it often on internet radios, music players, STBs, even picture frames. And not just on 10% of them - I'd say more like 40%.
But "not branching" may turn out to be more expensive than the branching overhead. In fact, this is often the case. The costs you saved by not branching are spent on hacks inside the stable branch to have the experimental bits only optionally enabled. (In C, its a sea of #ifdef/#endifs.)
First, all of these methods are hacks. Putting experimental, disabled code in your stable release is a really ugly hack.
Second, sometimes you cannot start small. If you replace an entire subsystem, you want to keep the current one until the new one is stable. A good example is a new renderer; software X has been using its old OpenGL renderer, but it just can't handle the ever increasing datasets anymore. So you write a new renderer Y, which CAN handle large sets. It is not possible to start small here; you cannot just develop "a little bit" of Y, neither can (and should) you introduce small changes in X, because Y is fundamentally different. In git, I create a branch for Y. It is especially useful in cases where components (like the renderer here) cannot be plug-ins, but need to be hooked in the main program. git merge vs. re-enabling all previously dormant code parts ...
And what about experimental code? Your solution would be to keep this experimental code locally on the HD until its either stable or determined to be useless, yes?
In git, I create a branch, put the experimental stuff in, if it turns out to be useful, I merge it with the head branch and remove the branch, if its useless, I just delete the branch. Meanwhile, I can continue developing and maintaining the stable branch. Try this with svn...
OpenGL is really lagging behind DirectX now.
Actually, its not. OpenGL is on par with Direct3D. It the API that sucks, because the core API no longer accurately reflects modern hardware, and everything thats nice is in new 2.1 features + extensions, which are progressing into an object model similar to Longs Peak. Therefore, right now OpenGL is a mixed bag - state machine style initialization for textures, object model style initialization for pixel/vertex/framebuffer objects & shaders.
Curved Surfaces are harder to control, require more logic in the chip (the triangle can be rasterized just by using 3 half spaces), are a royal pain for collision detection, look awful for anything that does not fit nicely as a curved surface, and can be approximated nicely using many triangles anyway. This tire is just badly modeled, thats all. Oh, and putting multiple types of primitives in the hardware is insane, nobody will do it. Even wireframe edges are simulated using thin triangles in typical GPUs.
If anything, I'd pursue research into cheap HW acceleration of voxel graphics. I guess the main obstacle here is memory, since voxels can get big pretty quickly...
Your "afraid to pursue any technologies that might make their existing technologies obsolete" statement is rubbish. You know this thing called "R&D"? This is where companies come up with new technologies that haven't been proven in the marketplace. Expect nvidia R&D for a hybrid renderer there.
And, AGAIN: raytracing is NOT a shiny new hammer for rendering. It CANNOT beat rasterization for surfaces that do not exhibit secondary-ray features (like any opaque, non-reflective surface, which usually make up ~60-70% of game scenes). This is why a hybrid renderer is more logical: ray tracing only pays off for secondary-ray effects like refraction or shadows. In fact, most papers that try to accelerate ray tracing include a special path for such surfaces, where standard rasterization is used. Its only Intel who's blabbering about pure raytracing.
What is happening? Why this brain-dead action? Why piss off people like this? The Mozilla crowd is being hit hard by WebKit, and this is their answer?
As usual, when politics get involved, everything goes down the drain.
Steve Jobs is not a human with a reality distortion field, Steve Jobs is a reality distortion field with a human body inside.
Well, you might want to tell Adobe that. Hint: they do use this modern C++ you abhor. You did use Photoshop, right?
Also, your conclusion is flawed. Since when does the best solution automatically win? The one which gets strongly pushed, hyped, marketed etc. is the one that wins, NOT the best one.
Instead of that they have been built using "toyish" (hey, they don't have things such as multiple inheritance etc what the C++ nerds always whine about) languages that actually lack most of the "nice" things of C++.
Yes, because 20 mediocre programmer code monkeys are cheaper than 4 top-class developers. Java is primitive, thus easy to grasp. C++ is not, even without the hideous syntax that artificially increases the difficulty. Its simple: if one language has more features and expressiveness than another, the latter is better suited for the average code monkey. Also, code monkeys are expendable, top-class developers are not. A manager's dream.
except that it takes 10 times more time to develop in C++
Now we have to be precise here. Remove enough bits of the Java standard library to equal C++'s in size, THEN judge again. People keep comparing plain C++ with a JDK-doped, Eclipse/IDEAI-enhanced Java. This brings us to Java's REAL advantage: its toolchain and SDK. Both are very good. Without them, the language is worthless.
Yes, this sounds logical. C++ has only recently become interesting. C++0x back in, say, 1999, would have totally killed off Java.