reliable way of rendering ?

hi,
been working on a texturefx script for some time now, and while implementation works well on ati or nvidia cards, there is a bigger issue with a friend’s laptop card.

now when trying to find workarounds for his card I stumbled upon following problems:

the drivers support ARB_multitexture and EXT_tex_env_combine

• display lists: cannot alter texcoords via texmatrix of mtex units (set before list is called, and list doesnt contain any texmatrix calls)

• texgen: will always use the “last” texgen mode for all mtex units. (e.g. let first be normal texture coords and last is SPHEREMAP, then both textures are drawn with spheremap)

• texmatrix: LoadIdentitiy eventually doesnt work, need to call a "scale with 111 and rotate with 0… to make sure nothing is changed.
  doesnt seem to affect ALPHA Buffer (e.g. in first pass rendered the image with modified tex matrix, and in second pass using DST_BLEND, the position of the “alphas” is as if no tex matrix change was done in first pass)

• texcombine: CONSTANT is all black

now with those problems (no issues on tested ati or nvi hardware), I wonder how do you actually know what you can expect to get on hardware and when to do it the safe way
like not using texture matrix but do it yourself and use texcoord arrays for all mtex units.

but how do you find out that e.g. CONSTANT isnt working on someones card ? Ask the user if he sees the effect ?

Hence I wonder, is it the “best” and most “reliable” way to do most things manually, ie. memcpy vertex data into a “render array” and then do texgen stuff manually yourself and flush that render array.
or use the “fastest” things you can get and hope that it works (display lists…) ?

it looks like one needs to create almost vendor specific renderpipeline and when you go beyond ati/nvi, its practially almost “ogl 1.1 only”

anyway it’s pretty interesting to see how different implementation on hardware is, kinda no surprise why gamedev loves consoles hehe
just am a bit frustrated after the long work being crushed by that laptop, needed a place to vent
but well since I am not as experienced as most people here are, I wondered what “backup path” exists, and how the pros deal with the multihardware issues…

is it like vendor specific pipelines and one pipeline for “worst scenario” or one pipeline which hopes to work best for most …

like how far back do you go when supporting older hardware, or is it just a “bad luck” for the user if his card&driver isnt doing what it should ?

What type of card is your friend using?

You can check extension strings at runtime and branch your execution accordingly.

the problems you’re describing are pretty strange indeed. I suspect either buggy drivers for whatever mystery card your friend has or errors in your code.

are you pushing and popping your texture matrix consistently?
are you correctly setting the current texture unit via glActiveTexture?
I’ve never heard of CONSTANT texture env mode.
do you mean GL_DECAL or GL_REPLACE?

doesnt seem to affect ALPHA Buffer (e.g. in first pass rendered the image with modified tex matrix, and in second pass using DST_BLEND, the position of the “alphas” is as if no tex matrix change was done in first pass)

there is no alpha buffer and im not sure what “alphas” are (translucent pixels?)
are you doing a glClear between the passes of your render (because that will obviously obliterate what’s in the frame buffer from the first pass).

more information is needed, and concise code samples could help us help you.

cheers.

yes I query extensions accordingly before using them.
its a sis 6325 chipset with integrated graphic card, shared memory…

the alphabuffer allows blends using DST_ALPHA it must be specifically set using GLUT and bpp must be at least 24.

GL_CONSTANT is a subfeature of GL_COMBINE texenvmode, which is part of tex_env_combine extension, which is available and works (just not glconstant as source).

and yes active texture and clientactivetex are set accordingly
I never push nor pop the texmatrix.

I suspect buggy drivers as well, the chipset is pretty old and it is a rather non “gaming” laptop. but it could stand for more people, hence I am a bit worried.
cause all other systems are nvi or ati, which I could test on so far.

okay here some code:

the evgl stuff is just a wrapper to minimize state changes:
evglselecttexture calls activetexture and clientactivetexture
modelmeshtexcoordgl wraps glTextureCoordPointer

if (stage->stagetype >= SHADER_STAGE_TEX)
{	// texture:
	evglSelectTexture( GL_TEXTURE0 +i +clr);
	evglBindTexture(stage->texID);
	glEnable(GL_TEXTURE_2D);
	glEnableClientState(GL_TEXTURE_COORD_ARRAY);
	if (!g_GLState.lockedVA){
		if (model != NULL && model->modeltype != MODEL_STATIC_GL)
			ModelMeshTexCoordGL(model,arg);
	}
	// do texcoords
	if (stage->stageflag & SHADER_SCREENMAP){
		glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
		glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_EYE_LINEAR);
		glEnable(GL_TEXTURE_GEN_S);
		glEnable(GL_TEXTURE_GEN_T);
		glMatrixMode(GL_TEXTURE);
		glLoadIdentity();
		glScalef(0.04,0.04,1);
		glMatrixMode(GL_MODELVIEW);
	}
	if (stage->stageflag & SHADER_SPHEREMAP){
		glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
		glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
		glEnable(GL_TEXTURE_GEN_S);
		glEnable(GL_TEXTURE_GEN_T);
	}

	if (stage->texcoord != NULL){
		glMatrixMode(GL_TEXTURE);
		glLoadIdentity();
		glScalef(stage->texcoord->tcScaleX,stage->texcoord->tcScaleX,1);
		glTranslatef(stage->texcoord->tcX,stage->texcoord->tcY,1);
		glRotatef(stage->texcoord->tcRot,0,0,1);
		glMatrixMode(GL_MODELVIEW);
	}
	else if (!g_GLState.nvi && !g_GLState.ati){
		// on sis chipset card loadidentitiy wasnt sufficient
		// hence manual reset
		glMatrixMode(GL_TEXTURE);
		glLoadIdentity();
		glScalef(1,1,1);
		glTranslatef(0,0,0);
		glRotatef(0,0,0,0);
		glMatrixMode(GL_MODELVIEW);
	}
	if (stage->color[0] > -1){
		glTexEnvfv(GL_TEXTURE_ENV,GL_TEXTURE_ENV_COLOR,stage->color);
	}
	// do texenv default is modulate
	if (pass->texcomb[i+clr].combiner){
		GLuint n;
		ShaderTexComb *texcomb = &pass->texcomb[i+clr];
					
		// okay this is a bit more funky
		// make sure setup creates the right stuff
		evglTexEnvf(texcomb->combiner);
		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_RGB, texcomb->mode);
		glTexEnvi (GL_TEXTURE_ENV, GL_COMBINE_ALPHA, texcomb->alphamode);
		
		for (n = 0; n < 4; n++){
			if (texcomb->srcs[n])
				glTexEnvi (GL_TEXTURE_ENV, GL_SOURCE0_RGB+n, texcomb->srcs[n]);
			if (texcomb->ops[n])
				glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_RGB+n, texcomb->ops[n]);
			if (texcomb->asrcs[n])
				glTexEnvi (GL_TEXTURE_ENV, GL_SOURCE0_ALPHA+n, texcomb->asrcs[n]);
			if (texcomb->aops[n])
				glTexEnvi (GL_TEXTURE_ENV, GL_OPERAND0_ALPHA+n, texcomb->aops[n]);
		}
	}
	else if (stage->texenvmode != 0){
		switch ( stage->texenvmode )
		{
		case GL_REPLACE:
		case GL_MODULATE:
		case GL_ADD:
		case GL_DECAL:
			evglTexEnvf(stage->texenvmode);
			break;
		}
	}
	else evglTexEnvf( GL_MODULATE );
	
}

• display lists: cannot alter texcoords via texmatrix of mtex units
  Display lists are static. This means that when a list is called, it will be executed with the parameters that were specified at the compile time of the display list. So altering variables that are used in parts of the code contained by the list, will not change the display list.

• texmatrix: LoadIdentitiy eventually doesnt work, need to call a "scale with 111 and rotate with 0… to make sure nothing is changed.
  doesnt seem to affect ALPHA Buffer (e.g. in first pass rendered the image with modified tex matrix, and in second pass using DST_BLEND, the position of the “alphas” is as if no tex matrix change was done in first pass)
  Try to avoid using the texture matrix. You can put this operation in the TexGen function by the following commands

glTexGenfv(GL_S,GL_EYE_PLANE, pointer to first row of texture matrix)
glTexGenfv(GL_T,GL_EYE_PLANE, pointer to second row of texture matrix)

the alphabuffer allows blends using DST_ALPHA it must be specifically set using GLUT and bpp must be at least 24.
You need 32 bits for alpha to work, 3x8=24 (RGB)
Don’t forget to specify both GLUT_RGBA and GLUT_ALPHA when creating the visual.

I can’t say much of the CONSTANT and “last” texgen problem without the code…

Nico

I’ve found drivers from vendors that are not the “big three” (ATI, Intel and NVIDIA) to not have sufficient level of GL support. If you want to expand beyond the 80% of the current PC market that those three give you, you need Direct3D.

Originally posted by -NiCo-:
Display lists are static. This means that when a list is called, it will be executed with the parameters that were specified at the compile time of the display list. So altering variables that are used in parts of the code contained by the list, will not change the display list.
That’s not correct. Executing a display list should repeat the commands that are in it and nothing else. If it doesn’t contain a glLoadMatrix(), then modifying the matrix outside of the list should still affect what’s in the list.

– Tom

as said the stuff works perfect on ati/nvi tested hardware…

but it looks like the only way to make it work for this card is to avoid combine, texgen and texmatrix and do it all manually

and the code given is pretty much it, after that comes just a glDrawElements or calllist

thx for the input

That’s not correct. Executing a display list should repeat the commands that are in it and nothing else. If it doesn’t contain a glLoadMatrix(), then modifying the matrix outside of the list should still affect what’s in the list.
Tom,

I said, altering variables. I wasn’t referring to gl commands.
Let’s say there’s a call like
glScalef(s[0],s[1],s[2]) for adjusting the texture matrix in the display list, then updating the values in the s-array after the list has been compiled will have no effect.

When I read “- display lists: cannot alter texcoords via texmatrix of mtex units”, I thought CrazyButcher meant that the display lists themselves could not alter the texture matrix.

Sorry for the misinterpretation.

NiCo

I edited that part now, to make it more clear. eventhough now things are cleared