Linking Program Problem

Then what could be wrong with this crashing at program link with no specific error from log info???


uniform sampler2D baseTexSamp;
uniform sampler2D bumpTexSamp;

//varying vec3 fragNormal;
//varying vec3 lightDir;

void main() 
{
    //float f = dot(normalize(lightDir), normalize(fragNormal));
    
	//gl_FragData[0] = vec4(clamp(f, 0.0, 1.0) * texture2D(baseTexSamp, vec2(gl_TexCoord[0])));
	
	gl_FragColor = vect4(texture2D(baseTexSamp, gl_TexCoord[0].st));
}

No vertex shader assigned, only this fragment.

Don’t double post. You already made a thread for this.

Till I get the answer :slight_smile:

How about an unspecific error? Does it put anything in the info log? Are you sure you’re querying the log properly? What exactly happens, does the application crash or nothing is drawn or what?

Nothing in the log, and it worked fine for other problem, so it’s not in the debug log.

While debugging the program, when it reaches to the link point it jumps to another place and crashes…

Another problem says at compile time of shader, EOF unexpected…but the syntax is 100% accurate.

vect4 -> vec4

Still with this code a problem but with compilation error:
pre-mature EOF


uniform sampler2D baseTexSamp;
uniform sampler2D bumpTexSamp;

varying vec3 fragNormal;
varying vec3 lightDir;

void main() 
{
	float f = dot(normalize(lightDir), normalize(fragNormal));
	
	//vec4(
	//clamp(f, 0.0, 1.0) * 
	//texture2D(baseTexSamp, 
	//vec2(gl_TexCoord[0])
	//)
	//);
	
	//gl_FragColor = texture2D(baseTexSamp, gl_TexCoord[0].st);
	gl_FragColor = texture2D(baseTexSamp, gl_TexCoord[0].st);

}

Did you compute the shader string length properly?

Yup. BTW I’m using C# Tao.OpenGL framework if that might be buggy and unreliable…I dunno all I can say damn .NET

Ok the problem sounds when I comment out the second sampler, bumpTexSamp, then it compiles. What a buggy ATI? or .NET?

Lol. I personally dislike both, but here I bet $10 on ATI’s fault. :slight_smile: They just suck sooo badly when it comes to drivers.

ok then switch to D3D!

Unfortunately it’s to be an implementation by some XYZ hardware vendor, so we don’t really care at least the casual users, gamers or CAD designers…if it makes their life better switching to D3D view in 3DS Max or in some games that support both then it’s not the card really. For OGL to be successful it should leverage itself from being an implementation to a driver. for graphics programming sake, it’s a damn robust API that needs a lot of dedication to get it out bug-free.

This bug seems to big to be a driver bug. Im sure they do some testing for such trivial case. Maybe you should try on a NVIDIA card to see if you can also reproduce the problem there.

When I wrote “both”, I meant .NET and ATI.

Now I tried it in pure “C” language, and I got the same eerroorr :smiley: