is assembly langage the only way to program vertex and pixel shader in opengl 1.4?
Yes, but it’s a “nice” assembler. That is, the code can be very readable since you use variables with names rather than registers like “r0” and so on as you do in Direct3D.
Yes??? What about Cg?
http://www.cgshaders.com/
That´s a way you can program vertex and pixel shader in a C like language, instead of assembly.
It´s currently quite nVidia specific, so that´s of course a drawback, but for starting to learn what one can do with shaders, it´s really nice.
Jan.
I heard that cg is not so good at the moment and they have some trouble with their compiler.
In any way i’m not afraid to use assembly 
where can i find some good code source?
nvidia specific? Doesn’t Cg work on ATI 9700’s if you use ARB_vertex_program and ARB_fragment_program profiles?
IF not why not?
Yes, it works on a Radeon. But i heard of many people having trouble with some stuff, because nVidia has some profiles for NV only. That´s also the reason why i said it´s a little NV specific, but of course not exclusive.
I had no clue of how to use vertex and pixel shaders, at all. I downloaded the Cg Toolkit and played a bit with it. I am not very good at it, cause i have enough other stuff to do at the moment, but i got a good look at what can be done.
Therefore i think Cg is very good, at least to learn to understand what shaders are. If you really want to do supergenius stuff, which runs on all cards, you may want to use assembly.
Jan.
A quick guess - arn’t those people who are crying about Cg all the time ATI “die hard” worshipers.
Cg is pretty good right now, of course you can do more in assembly, but why the hell you are using C,C++,Delphi etc. so much? Moreover, think about NV30 huge instruction count, even Carmack said that it’s nice field for developers & imagine all that stuff in assembly 
Assembler’s not so bad once you get used to it. After a while it becomes second nature. It’s certainly alot easier to program with ARB_fragment_program than with ATI_fragment_shader, given that instructions are no longer input via functions. However, I do admit that it can have quite a steeper learning curve, as compared to high level languages.
Originally posted by M/\dm/
:
A quick guess - arn’t those people who are crying about Cg all the time ATI “die hard” worshipers.
Cg is pretty good right now, of course you can do more in assembly, but why the hell you are using C,C++,Delphi etc. so much? Moreover, think about NV30 huge instruction count, even Carmack said that it’s nice field for developers & imagine all that stuff in assembly
I use Cg to only generate chunks of code for something, so it doesn’t matter what card I use (I optimize it by hand later). I would never use it in a “professional” application though, as it still could use some reworking on the optimizer.
Just IMO.
There’s nothing terribly wrong with Cg. The problem however is that it’s controlled by a single vendor and really doesn’t fill any empty slots, at least not given that D3D already has it’s HLSL and OpenGL is soon to get one. Todays shaders are short enough to be written in assembler without any real problems at all. Also, I’ve heard (but don’t know if it’s true) that the Cg compiler currently generates far from optimal code.
i was wondering if the programmable shader are based only ( or mostly ) on the texture computing?
i mean input, output, variables should be texture as i can see in opengl 2.0 white papers.
Well, you have textures as input but also texture coordinates and constants of course. You have specific output variables that writes the stuff to your framebuffer.
Is there a way to pass vertex attributes ( like texcoord or color ) from the vertex program to the fragment program to make some computation, using asm?
Or maybe use the output from the vertex program as input for the fragment program?
Yup. You have certain outputs from the vertex shader, texcoords, position, colors, fogcoord etc. Texcoords/colors etc can be read by the fragment program.