With the introduction of vertex and pixel shaders, a whole new branch of graphics programming has opened up. I’ve been checking out because…well it’s just cool. I’ve run into Cg and well the built in directX shading language. I was wondering if you guys know of anyother shading languages out there. I can’t remember what the language opengl 2.0 is going to include is. I knwo it was that or Cg and Cg lost.
What are you opinions on the languages? Which one do you guys like better? i for one would have LOVED to see Cg implemented in openGL, but that's partially because i'm a HUGE Nvidia fan. DirectX's language sucks. I mean yeah they are the pioneers...but i mean you have to write scripts in different versions of the language for different video cards. PS1.4 does not work on Nvidia...and being the fan i am of that company, it makes me mad. [img]http://www.opengl.org/discussion_boards/ubb/mad.gif[/img]
Anyway, I aways like to get my hands dirty, and do it all in ASM (ARB_v_p & ARB_f_p). I’ve always found that Cg just plain sucks at ANY kind of optimization, and I have to go over the output anyway (mostly burning my damned registers).
OpenGL 2.0’s on the other hand I could get use to, but I still like ASM.
Hey i’m into assembly too. Well atleast for shading. That’s one of the reasons i like the directx shading language. I just dont’ like how there are different implementations of it and how they work on different cards. Like PS.14 ONLY works on the new ATI card. What’s the opengl2.0 syntax like and where do i get info on it? A link would be super helpful.
This is my personal opinion, so I hope no one gets super angry at what i'm about to say. But directx 8.1 is a lot like opengl now. I mean it's fairly easy to use and stuff... The only thing i wish it had was a better way to declare the vertices...it does make a lot of things easier. I still love opengl more, because it's meant to do so much more and the fact that it stays in the fight with so little updating is a tribute to how well designed it is. DirectX recieves so many MAJOR upgrades that it changes the syntax a lot. OpenGL just adds a few procedures here and there and with the 2.0 adds in a new shading language to go along with teh procedures. But there are a few things in OpenGL that kinda tick me off sometimes. I know it's made so it can be done in C and all, but most programs made now are classes. It would be kinda nice to have that...that is the only thing that kinda keeps directx in the game for me...the object-oriented-ness. So basically, DirectX isn't that bad...but OpenGL is just better [img]http://www.opengl.org/discussion_boards/ubb/biggrin.gif[/img]
So thanks in advance for the links to the OpenGL shader language.
Yeah, it would be nice if more companies had support for PS 1.4 (YEAH, I’M LOOKING AT YOU NVIDIA), but hey, what can you do? Not much.
Seems to be the way of computer graphics, one IHV will use one “standard” while other won’t use that one because that vendor is using it. Pisses me off, but alas theres nothing I can do about it.
When is Nvidia coming out with their next card? If i remember correctly, the GeForce 4 was the last one in their GeForce series. It’d be nice to see some competition to the 9700. ATI is an awesome company…but it isn’t my favorite you know!!
Puting classes into OpenGL 2.0 would be a bad move, since it would be effectively saying “screw you” to those programmers who still prefer straight C to C++. There are still valid reasons to use C, and there are still valid reasons to use assembly language.
Classes do not equal object oriented. Classes facilitate object oriented code, but you can write very good, very object oriented code without classes.
Furthermore, object oriented code is not equivalent to good code. Object oriented code is not even the right answer to a lot of problems. It is a useful paradigm and a popular buzzword, but it is also too easily and too often elevated into a golden ideal for all computer programming.
For what it’s worth, the low-level APIs will converge for current/near-future hardware with ARB_fragment_program (and have already basically converged with ARB_vertex_program).
Unfortunately, there are significant differences in the prior generations of hardware that are difficult to bridge, and that hardware is overall far less programmable than the new generation, particularly at the fragment level. My limited understanding is that DirectX has incompatible PS 1.3 (NVIDIA) and PS 1.4 (ATI) interfaces that are mutually incompatible.
It would have been possible and valuable to create some kind of least common denominator DX8-level API in OpenGL, but the bang-for-the-buck is much lower now than it was a year or two ago.
What you say is totally right, and i phrased myself incorrectly. I guess what i meant was just encapsulating a few of the things. I'm assuming you are referring to my post in the suggestions for opengl 2.0. What i was trying to say is that it'd be very very nice to provide some classes wrapped around the most basic thing like fonts. But still provide all the c style functions so you could code straight c. I dunno...just a personal thing. But i can [b][i]totally[/i][/b] see how keeping it at full C is probably a better alternative. Users can build their own encapsulations and what not.
I hope they publish an official book on their shader language, cuz that looks like it’s gonna kick butt!!!
For what it’s worth, the low-level APIs will converge for current/near-future hardware with ARB_fragment_program (and have already basically converged with ARB_vertex_program).
When the mentioned future finally comes (that is - when DX8 HW goes out of market), the convergence which ARB FP would give will be practically useless because all work will be done with HLSLs.
Unfortunately, there are significant differences in the prior generations of hardware that are difficult to bridge, and that hardware is overall far less programmable than the new generation, particularly at the fragment level. My limited understanding is that DirectX has incompatible PS 1.3 (NVIDIA) and PS 1.4 (ATI) interfaces that are mutually incompatible.
It is not interfaces that are mutually incompatible in DX, but only languages - the very difference.
This topic has already been on this forum (about ARB meeting notes) and you basically repeated your statement. Excuse me, but I can’t understand why you still continue to ignore the fact how DX8 1.0, 1.2, 1.3, 1.4 DX shaders are designed. They do coexist, despite big differences. There is no need to look for common denominator on language level, beyond that found in DX (now, I just repeated my statement). DX8 exists, and is living proof that what you are saying is just false. DX programmers are free from artificial incompatiblities like shader object managment, parameter loading, texture target priority handling (allusion to ATI_text_fs). Why OGL programers cant have it?
It would have been possible and valuable to create some kind of least common denominator DX8- level API in OpenGL, but the bang-for-the-buck is much lower now than it was a year or two ago.
I think it far too early to claim this. DX8 shaders are not even the main game target yet, and it will take few years to be pushed out of minimal HW requirements. On This forum there used to be plenty of posts from people asking for above changes. Now it is no longer, because people just gave up (including myself), and probably many of them just write their own wrappers to patch the API (including myself).
MZ: I’m not saying that the situation we are in with completely incompatible fragment shading interfaces prior to ARB_fragment_program is ideal, or even defensible.
There are real differences between the functionality of the different implementations that do show up in the makeup of the extensions. The ATI_text_fragment_shader extension does look considerably different from ARB_fragment_program, as an example. But I agree that different languages using the same interface is better than the mess that we have now.
The reality of the situation is that most HW vendors are REALLY busy working on current and future hardware and corresponding software. Adding another effort to fix the mistakes we made several years ago is a tough pill to swallow.
The sporadic feedback I’ve gotten on this subject is that this would be a very useful feature to have. But it really hasn’t seemed all that strong. And I’m sure I’ve missed some of it. I’m definitely sympathetic, but it would be a tough thing to add. Even if all the key ARB vendors were on board, implementations probably wouldn’t start showing up until Q2 2003 at the earliest. Add even more lag time before things start showing up in actual titles.