Hello.
I am curious about the purpose of glProgramLocalParameterI4* family functions? I found out that calling:
int data[4];
glProgramLocalParameterI4ivNV(target, id, intData);
and
int data[4];
glProgramLocalParameter4fvARB(target, id, (float *)intData);
leads to same result (integer data is passed to a vertex program). Vertex program was compiled with cg (ver. 2.2) -profile=gp4vp, and loaded via glProgramStringARB call.
Thanks in advance.
They should lead to the same result. Remember, only until recently have integral values in shaders actually been real integers; before now, they were just floats treated as integers. So glProgramLocalParameter4fvARB always worked.
It’d be bad form to break backwards compatibility by making glProgramLocalParameter4fvARB not work on parameters it used to work on.
And what about that integer in float form may cause some FP exceptions? I’ve heard somewhere, that if we are loading integers, we SHOULD call integer function, not float one. I mean, loading just as AlexeyAR5 mentioned, with C-style binary cast.
Anyways I don’t see what the gain is to use fv instead of iv… Is it to save one “if” statement per uniform upload? I think you’re testing your luck by using non standard paths. Some standard paths which are not used that much by code “out there” occasionally have bugs, so I would want to steer clear of non-standard ones unless they give a BIG benefit!
How could it give the same results? If one of your values is 569 and you want the raw bits to be treated as floats, you certainly won’t get 569.0
Also, glProgramLocalParameter4fvARB comes from GL_ARB_vertex_program and glProgramLocalParameterI4ivNV comes from
GL_NV_gpu_program4 so you are mixing up extensions.
Result are same, because shader treats input parameter as integer (in my case), no matter how the parameter is passed.
...
TEMP R0;
I2F R0.x, c[4];
...