Slashdot Mirror
ATI Releases Competition for NVIDIA's Cg
death00 writes "ATI has released a beta of RenderMonkey, their suite of open, extensible shader development tools. ATI showed these tools for the first time at Siggraph 2002. Should be interesting to see who wins the shader development race, NVIDIA's Cg, RenderMonkey or whatever 3Dlabs has on the go."
"Should be interesting to see who wins the shader development race, NVIDIA's Cg, RenderMonkey or whatever 3Dlabs has on the go."
Or maybe nobody wins. Maybe three uncompatible ways to do things will hurt developers.
What they should be doing is to reach an agreement and put it onto opengl.
When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
Why dont they work together and stop thinking about the shareholders! It would be positive for everyone involved.
If RenderMonkey is better the Cg, then great! Cg can then try to leapfrog RenderMonkey, and then the API for both just gets faster, more reliable, and easier for developers to use.
[rant]
I'm going to be building myself a new PC shortly, and I'm going to put an ATI Radeon 9700 in it.
Personally, I've been pretty upset with NVIDIA ever since they bought out 3dfx and told Voodoo owners to go screw themselves, that they weren't releasing any new drivers or supporting any Voodoo products. I bought a Voodoo5, instead of a Geforce2 - due to the stability of the Voodoo2 and Voodoo3 I had owned, and due to reading the complaints about NVIDIA's drivers... and a week later 3dfx went under. D'OH!
- Cg is a high-level shading language (compatible with DirectX 9's HLSL) that will compile to both DirectX and OpenGL APIs, or to various sets of OpenGL extensions, even at runtime if desired.
- Render Monkey is an IDE that supports various shading languages, including Microsoft's (and therefore Cg, at least when they add DX9 support). AFAIK, it's not that dissimilar to nVidia's own Effects Browser.
- OpenGL 2.0 is a lot more than just a shading language, but in any case, it's still at the proposal stage. Cg may yet be adopted for the language, but it will likely end up being quite similar at least.
So I see no reason why you couldn't write your shaders in Cg (sorry, DX9 HLSL) within the RenderMonkey environment, and then compile your results to OpenGL 2.0.
nVidia have said they'll support whatever the ARB decides, but even if OpenGL 2.0 does use the 3DLabs language, there's no particular reason you couldn't use a Cg profile to output an OpenGL 2.0 HL shader, or an ARB_vertex_program shader, or something even lower-level.
Hell, why not just write your shaders in RenderMan & then use RenderMonkey or Effects Browser or whatever to import the RIBs & compile that down. Ever wondered why nVidia bought Exluna? There's a lot of RenderMan expertise right there...
Why would anyone engrave "Elbereth"?
Good old JC (John Carmack :) wrote/talked about this briefly a little while back (i can't remember where)
.plan, or his address from QuakeCon 2002. I think this is where he talks about it.
Basically, like the difference between C and ASM, you will be sacrificing speed and smaller code size for easier readability, maintainability, and faster production time. Because hardware has become so advanced, the switch is nessesary because the programs are getting so complex. Of course, there will always be the guys who hand code everything in ASM, but for most people, especially game dev studios who have specific budgets and deadlines, you have to take it because of the time it can save.
Check Carmack's
I think that you and the parent are missing the real reason that OpenGL is king on the workstations and Direct3D never will be. OpenGL is extendable by everyone and Direct3D is completly controlled by MS.
That's very true, but you also missed the reason that Direct3D got where it is today, because OpenGL was definitely the king in games up until at least DirectX5. The reason is simply that Direct3D is updated on a fairly regular basis to take advantage of the new features on video cards as quickly as possible (and those features are most often geared towards what the game developers want to see), whereas such support is provided in OpenGL only through those card-specific extensions most of the time (as it takes much longer for OpenGL itself to be updated with those features).
OpenGL is a much more static API and that has it's own appeal in areas where your application may be in use for several years, rather than just the 60 hours that a player may spend on your game. As long as people believe that they need the latest flash-bang-gizmo graphics tricks in order to sell their games, they'll want the API they use to make their lives easier when they use those tricks. Even the idea that OpenGL is faster can be questioned when looking at cards that support the calls being used (though that certainly wasn't the case in earlier versions of Direct3D, which were always slower than properly-written and supported OpenGL).
You can't go and make your own version of Direct3D with a hypercube (or whatever) extension that draws a super widget because Direct3D is closed.
Then again, any graphics chip manufacturer is free to add new features to a card and give the developers the ability to use them alongside Direct3D before Direct3D supports them. This is basically what nVidia and ATI are doing with Cg and RenderMonkey (giving them a higher-level language that compiles down to hardware-level code for DirectX8 while also compiling to OpenGL and DirectX9 code for those calls that are (or will be) supported).
-PainKilleR-[CE]
I do game programming, sometime.
I do it in assembly language, almost always.
As an aside, are you still using assembler for everything? If so - why? You should be concentrating on the game, being as productive as possible and building 100% of what you're doing in a higher level language (such as C++).
When you're done, the last phase of your optimisation should be converting the most performance-critical sections of the program to assembler if it's still needed after optimising your higher-level language code. For a modern game this shouldn't be more than about 5%, if at all - particularly if it uses 3D acceleration.
If your game development is a hobby, nevermind - you should be in it for the enjoyment, not the productivity.
Hemos, your thoughts about the liability of corporate employees is not entirely true.
Under most U.S. law (mostly State law relating to fiduciary obligations of Directors, Officers & Executives (DOE)), the standard is called the Business Judgement Rule (BJR).
Under the BJR, a DOE is protected from suits for breach of fiduciary duty if the DOE (1) is disinterested (i.e. financially independant of the outcome), (2) acts in good faith, and (3) exercises due care in reaching the decision.
Every decision that a DOE makes does not have to directly accrue to the financial benefit of the corporation. Corporations can, and are expected to, contribute to the local community, support charities, exercise some respect for the environment, i.e perform "good acts".
These "good acts" will not always (or even ever) benefit the corporation financially. Nonetheless, DOEs are never successfully sued because they should have given a dividend instead of donating a piece of land to the city for a park, decided to give employees a day off to help with Habitat for Humnaity, or install CO2 scubbers when the fines are cheaper.
So, contrary to what I see posted on Slashdot frequently, every decision an employee of a company makes DOES NOT have to be the short-term, profit-maximizing decision. Believe it or not, the law allows some leeway in the decision making of running a company.
For more information, see this link
(and please don't respond with "but Enron...." or "look at WorldCom, Global Crossing, etc." I am speaking about the applicable law of fiduciary duties, not engaging in a public policy debate or Crossfire-esque corporate-bashing)