My implementation skips + and - signs

Hi All,

Just after putting my shader at work I discovered that my fragment shader doesn’t evaluate the + and - signs while it correctly evaluates the * and / signs.

So if I use

pos.x = pos.x + 10

pos.x is unaffected, while

pos.x = pos.x / 2

pos.x is affected.

I define the shader source as string in C# and after reading the following article I start to be concerned about the source code string encoding.

What do you think?



try to output the string in a file, to see if it is well encoded.

And I suggest you to use the .0 suffix when affecting a scalar value to a scalar type. There is not implicit type casting.

Is there no way to read back the program source from a copiled shader? I think this would be the best test I can do…



The string you compile is the the one you give to the compiler, so you need to be sure that tihs string is well fitted.

Looking to the string in visual studio, the string is fine.

Do you think that if I write it to a txt file I see something different?



Yes this is what I suggested to you, but I don’t know if it would be different.
I don’t understand why the compiler would skip operator +, there must be a syntax error somewhere else and this would be more visible in a text file.

Just a question, why do you code a shader in a string in the middle of C# code? This is awkward I think.

If you have Nvidia card you can use the NVemulate tool (maybe the GLExpert can do that too, I am currently not sure) to force the driver to write both source (as the driver sees it) and compiled shader + compilation logs into files put into application directory.


This is a very easy and short shader, I thought it could be stored within the code.

Am I the first that declare the source code as a string instead or reading it from a txt file?




Unfortunately we are all using ATI graphics cards…



Use to do a XML frame grab and look at the shader source?

Very nice tool thanks.

It says what you see below. By the way if I uncomment the commented line I see the texture altered while the line “pos.x = pos.x + 20.0;” don’t affect my texture. Does another reason exist? It is a problem to query a .st value out of the texture size?

/*== INFO LOG ==
Fragment shader(s) linked, no vertex shader(s) defined.d  == INFO LOG END ==*/

//   Fragment Shader 1

/*== INFO LOG ==
Fragment shader was successfully compiled to run on hardware.  == INFO LOG END ==*/

// maximum size supported by this shader
const int MaxKernelSize = 49; 

// size of kernel (width * height) for this execution
//uniform int KernelSize;
const int KernelSize = 49; 
// array of offsets for accessing the base image
uniform vec2 Offset[MaxKernelSize];

// value for each location in the convolution kernel
uniform vec4 KernelValue[MaxKernelSize];

// image to be convolved
uniform sampler2D BaseImage;

void main()

    int i = 0;
    vec4 sum = vec4(0.0);

    for (i = 0; i < KernelSize; i++) 
        vec4 tmp = texture2D(BaseImage, gl_TexCoord[0].st + Offset[i]);
        sum += tmp * KernelValue[i];

    vec2 pos = gl_TexCoord[0].st; 

    pos.x = pos.x + 20.0;
//  pos.x = pos.x / 2;

    gl_FragColor = texture2D(BaseImage, pos);


what texture wrap parameters do you use?

Default ones. We don’t change them.

default texture wrap mode is GL_REPEAT for all texture cordinates. So the integer part of each coordinate is ignored.
That explains why adding a big round value like 20 doesn’t change anything.

So these are float coordinates from 0 to 1 ?

I was always thinking about pixel coords.

Thanks so much,


Just to confirm, texture coordinates are from 0…1 (unless you are using a rectangle texture)

Yes, in repeat mode texture coordinates are actually considered in [0, 1] interval and independant of texture size.

Thanks guys, my shader is now alive.

sqrt, go on developing and supporting that nice tool!


Yes sqrt[-1], good precision! :slight_smile: I forgot this one.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.