Jump to content
The Dark Mod Forums

TDM Engine Development Page


zergrush

Recommended Posts

Well OpenGl still keeps compatibility with older abi versions but yeah support will get shoddy sometime in the future.

ASM also has a few things its not capable of like motorsep said, the question is then can we live without those abilities ?.

Reason BFG's glsl code is so massive is that besides handling GLSL calls it is also able to convert other types of shader languages like hlsl and CG to GLSL,

Leving that part out it would shrink considerably, still it would fill a bit more than the assembler version but nothing close to what it does now.

A donation page for getting a dev to solve these parts is a good idea :) ill donate when my paycheck rolls in tuesday.

Link to comment
Share on other sites

Thanks, but wow! That's a bit more code than I expected. I didn't realise that glsl requires the client code to set up an entirely different context. I'll shelve that for now and just learn ARB assembly to play with soft particles, which will take an hour instead of weeks.

 

Do we want glsl? While reading Real-Time Rendering I noticed that the authors warn repeatedly against branching code because all branches have to be executed. I can see why that's a problem in assembly, but does glsl solve it? If so it's worth working on. But we couldn't use the full glsl port without translating all existing shader programs to glsl. Even so, that might be less work than a hybrid solution if the one that revelator linked supports only interactions. I've not checked it out yet but I'm sure they'd have supported everything if it were easy.

 

Yeah, in the long run we would want GLSL. One thing that's cool about this is that it doesn't need to interfere with the main project since

everyone can just use r_renderer Best (which defaults to ARB2) while others tinker with GLSL. You could even ship it with the mod while

still in WIP since you end-users would generally never switch the render path in-use.

 

As for converting ARB to GLSL conversion, it might be possible to use this: http://icculus.org/mojoshader/ to do the conversion.

 

(Thanks for the donation AH! )

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

A donation page for getting a dev to solve these parts is a good idea :) ill donate when my paycheck rolls in tuesday.

I'm extremely unconvinced of that, based on experience from my day job of handling code contributions from consultants. You can pay a consultant to spend a day writing code, but you generally can't pay him or her to spend 30 days familiarizing themselves with the existing architecture so that what they produce fits in and doesn't make future development twice as hard. The gap would narrow if the current architecture were documented somewhere other than the code itself, but it isn't.
Link to comment
Share on other sites

ASM also has a few things its not capable of like motorsep said, the question is then can we live without those abilities ?.

 

A better question is if TDM will ever switch the engine. It that would be on the roadmap, it would make sense to go all out about choosing a fork, features, etc. As it seems to stand now, no one is going to switch anywhere, unless someone takes TDM engine and modify that.

 

Reason BFG's glsl code is so massive is that besides handling GLSL calls it is also able to convert other types of shader languages like hlsl and CG to GLSL,

 

That is not correct. BFG engine takes Cg shader, and generates GLSL/HLSL/CGB out of it (PC/XB360/PS3). You could technically write all of those shaders straight out, skipping Cg. But the engine was designed to make it easier to author shaders at once for all platforms (although CGB part is not in the GPL code base). The parser maybe makes up a large portion of the code (it's not even rendering code technically speaking), but rendering code is larger because it's threaded, and because it comes from RAGE - different rendering architecture when comparing to Doom 3.

 

There are 2 parts that are necessary to improve in order to gain performance - skinning and shadows. Going with GPU skinning and shadow mapping will get you the max performance. That's why going with BFG is a much better option in a long run, than patching up idTech 4 making mess out of it.

 

However, that's a very nature of unpaid FOSS development :)

Link to comment
Share on other sites

3 actually. Reason i started digging deeper into BFG's thread handler is that vanillas thread code is not very mature.

 

1: It uses async threads which is ok for the most part if done right.

2: only a few functions in vanilla are threaded 2 actually.

3: i ran it through a debugger to see what kind of improvement i could expect.

 

as for 3 i can say a rather substantial improvement,

vanillas thread code spends a lot of time waiting for thread locks and that is causing some rather substantial lag i noticed.

try gdebugger its free and its pretty handy when you want to find out where you can do the most good :).

 

as for BFG's GLSL code its still just filler, it might be nice filler but do we need it ? that was what i would like to know :).

 

Porting to BFG sure, but we still have the minor problem that it does not allow mods in the sense we are used to.

+ sides of BFG its faster no doubt about that.

Its multi threaded by nature.

Thanks to robert beckebans we have shadow mapping.

Vertec buffers are a lot more mature.

 

Not so nice.

Menu's are in flash.

Not able to make small changes to game code for personalization,

could recompile the lot ofc but it would not be compatible with the unmodified version,

unless you want to litter the code with #ifdefs and whatnot.

 

This is ofc up to personal preference,

but as a coder im allways looking to improve existing code rather than totally scrap it (i only do that when its completly broken).

Lord Havoc could just have waited for the next big thing in the id source world but then we would not have darkplaces :).

 

Thats my reason.

Everyone is entitled to there own though.

  • Like 2
Link to comment
Share on other sites

Yeah, it's hard to say how much of the BFG code that Pat Raynor ported to Morpheus is in excess. The biggest gain there is that you can

use the GPL'ed GLSL shaders that are packaged with BFG source rather than having to reverse engineer vanilla's ARB shaders.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

That and to be frank the vanilla shaders are not Open source the GLSL versions are.

A good deal of graphics mods actually break the eula by using modified id ASM shaders.

 

Raynor ported the GLSL renderer and code for parsing GLSL - the gpu skinning part, it was still missing the interactions with the model shaders but that part is pretty easy, can pretty much use the code for that with no modification from BFG.

The hard part would be getting the rest of the code in draw_common.cpp ported (mostly effects) GLSL uses a bit different code there.

Link to comment
Share on other sites

A good deal of graphics mods actually break the eula by using modified id ASM shaders.

 

TDM / Hexen use ARB shaders written from scratch. But again, the issue is that it's virtually impossible to find graphics programmers who can (or will, even if they could) write shaders using assembly. So maintenance and long term support are the major issues too.

Link to comment
Share on other sites

One thing that's cool about this is that it doesn't need to interfere with the main project since everyone can just use r_renderer Best (which defaults to ARB2) while others tinker with GLSL. You could even ship it with the mod while still in WIP since you end-users would generally never switch the render path in-use.

 

I think I see what you mean... while it's a WIP the game defaults to using ARB still, but the user can switch to glsl on the fly using the console command. That would get screwed up by the material files though, wouldn't it? They point to the text files containing the shader progs, so we'd need some way to swap them out. Which could get a bit complicated. Or can you mix shader languages in a single file?

 

As for converting ARB to GLSL conversion, it might be possible to use this: http://icculus.org/mojoshader/ to do the conversion.

 

It doesn't look like it does file conversion, it acts as a run-time interpreter. But the discussion is pointing to a glsl port being a good idea. We have 150 shader progs, so it's borderline whether setting up an auto conversion would be easier than rewriting them. They tend to be short and they should be easy to recode and many will turn out to be unused but still, there are quite a few.

 

I noticed that the authors warn repeatedly against branching code because all branches have to be executed. I can see why that's a problem in assembly, but does glsl solve it?

 

Does no-one know the answer to this? I'll report back if I find out first.

Link to comment
Share on other sites

Oh yeah, that is the trick isn't it... Material shaders. Light shaders pose no challenge since they aren't called by the material definition but

stuff like glasswarp or any surface program will be a problem for existing maps that use those unless you encode some sorta fallback.

That seems to be related to Revelator's post about draw_common too, I think that all comes down to these types of effects. I guess it's kinda

a good thing that the material system didn't really gain much from calling ARB shaders directly since anything that didn't involve transparency

wouldn't work with lights most of the time. I remember reading about the frustration folks had at Doom3world trying to do things like Fur shaders.

If they only knew back then that they would need to pack that stuff into the main light interaction rather than try to call it as a material property.

(Of course, without the ability to specify new surface attributes or new texture inputs, such knowledge would just be another quagmire of hacky

workarounds anyway...)

 

ARB assembly has no branching support at all as I recall. Though I believe you can fake it using a stencil test (which would be complicated here

since the engine is already using the stencil test for overdraw reduction).

 

GLSL has branching but can suffer from "shader combinatorial explosion". This can be fixed via https://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt

but requires OpenGL 4.1 drivers.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Thats exactly what i mean :) damn someone finally understands.

The GLSL backend is not hard you can copy it pretty much unmodified from BFG the hard part is all the damn special effect code like glasswarp etc in draw_common.cpp

Then again looking at BFG it seems a good deal of those are not even used in vanilla as they have been removed from BFG, notice a certain printf in the above source file with a comment about contacting steve in case the thing blows up because of the lack of them :).

 

If need be and someone actually wants those effects we could copy of the non shader versions from the older backends,

but that would be a step back that im not certain would be wise.

 

The GLSL backend does however leave the door wide open for shader devs to fill in those spots in there own mods :)

A fur renderer for instance woukd make for some extremely realistic hair (as long as it does not go as far as furmark, were not building a benchmark here hehe).

But first we need to get the basics working, which i would be happy to help with.

Link to comment
Share on other sites

Heh im glad i make you smile :P

 

but

 

static void RB_PrepareStageTexturing( const shaderStage_t *pStage,  const drawSurf_t *surf ) {
float useTexGenParm[4] = { 0.0f, 0.0f, 0.0f, 0.0f };
// set the texture matrix if needed
RB_LoadShaderTextureMatrix( surf->shaderRegisters, &pStage->texture );
// texgens
if( pStage->texture.texgen == TG_REFLECT_CUBE ) {
	// see if there is also a bump map specified
	const shaderStage_t *bumpStage = surf->material->GetBumpStage();
	if( bumpStage != NULL ) {
		// per-pixel reflection mapping with bump mapping
		GL_SelectTexture( 1 );
		bumpStage->texture.image->Bind();
		GL_SelectTexture( 0 );
		RENDERLOG_PRINTF( "TexGen: TG_REFLECT_CUBE: Bumpy Environment\n" );
		if( surf->jointCache ) {
			renderProgManager.BindShader_BumpyEnvironmentSkinned();
		} else {
			renderProgManager.BindShader_BumpyEnvironment();
		}
	} else {
		RENDERLOG_PRINTF( "TexGen: TG_REFLECT_CUBE: Environment\n" );
		if( surf->jointCache ) {
			renderProgManager.BindShader_EnvironmentSkinned();
		} else {
			renderProgManager.BindShader_Environment();
		}
	}
} else if( pStage->texture.texgen == TG_SKYBOX_CUBE ) {
	renderProgManager.BindShader_SkyBox();
} else if( pStage->texture.texgen == TG_WOBBLESKY_CUBE ) {
	const int *parms = surf->material->GetTexGenRegisters();
	float wobbleDegrees = surf->shaderRegisters[ parms[0] ] * ( idMath::PI / 180.0f );
	float wobbleSpeed = surf->shaderRegisters[ parms[1] ] * ( 2.0f * idMath::PI / 60.0f );
	float rotateSpeed = surf->shaderRegisters[ parms[2] ] * ( 2.0f * idMath::PI / 60.0f );
	idVec3 axis[3];
	{
		// very ad-hoc "wobble" transform
		float s, c;
		idMath::SinCos( wobbleSpeed * backEnd.viewDef->renderView.time[0] * 0.001f, s, c );
		float ws, wc;
		idMath::SinCos( wobbleDegrees, ws, wc );
		axis[2][0] = ws * c;
		axis[2][1] = ws * s;
		axis[2][2] = wc;
		axis[1][0] = -s * s * ws;
		axis[1][2] = -s * ws * ws;
		axis[1][1] = idMath::Sqrt( idMath::Fabs( 1.0f - ( axis[1][0] * axis[1][0] + axis[1][2] * axis[1][2] ) ) );
		// make the second vector exactly perpendicular to the first
		axis[1] -= ( axis[2] * axis[1] ) * axis[2];
		axis[1].Normalize();
		// construct the third with a cross
		axis[0].Cross( axis[1], axis[2] );
	}
	// add the rotate
	float rs, rc;
	idMath::SinCos( rotateSpeed * backEnd.viewDef->renderView.time[0] * 0.001f, rs, rc );
	float transform[12];
	transform[0 * 4 + 0] = axis[0][0] * rc + axis[1][0] * rs;
	transform[0 * 4 + 1] = axis[0][1] * rc + axis[1][1] * rs;
	transform[0 * 4 + 2] = axis[0][2] * rc + axis[1][2] * rs;
	transform[0 * 4 + 3] = 0.0f;
	transform[1 * 4 + 0] = axis[1][0] * rc - axis[0][0] * rs;
	transform[1 * 4 + 1] = axis[1][1] * rc - axis[0][1] * rs;
	transform[1 * 4 + 2] = axis[1][2] * rc - axis[0][2] * rs;
	transform[1 * 4 + 3] = 0.0f;
	transform[2 * 4 + 0] = axis[2][0];
	transform[2 * 4 + 1] = axis[2][1];
	transform[2 * 4 + 2] = axis[2][2];
	transform[2 * 4 + 3] = 0.0f;
	SetVertexParms( RENDERPARM_WOBBLESKY_X, transform, 3 );
	renderProgManager.BindShader_WobbleSky();
} else if( ( pStage->texture.texgen == TG_SCREEN ) || ( pStage->texture.texgen == TG_SCREEN2 ) ) {
	useTexGenParm[0] = 1.0f;
	useTexGenParm[1] = 1.0f;
	useTexGenParm[2] = 1.0f;
	useTexGenParm[3] = 1.0f;
	float mat[16];
	R_MatrixMultiply( surf->space->modelViewMatrix, backEnd.viewDef->projectionMatrix, mat );
	RENDERLOG_PRINTF( "TexGen : %s\n", ( pStage->texture.texgen == TG_SCREEN ) ? "TG_SCREEN" : "TG_SCREEN2" );
	renderLog.Indent();
	float plane[4];
	plane[0] = mat[0 * 4 + 0];
	plane[1] = mat[1 * 4 + 0];
	plane[2] = mat[2 * 4 + 0];
	plane[3] = mat[3 * 4 + 0];
	SetVertexParm( RENDERPARM_TEXGEN_0_S, plane );
	RENDERLOG_PRINTF( "TEXGEN_S = %4.3f, %4.3f, %4.3f, %4.3f\n",  plane[0], plane[1], plane[2], plane[3] );
	plane[0] = mat[0 * 4 + 1];
	plane[1] = mat[1 * 4 + 1];
	plane[2] = mat[2 * 4 + 1];
	plane[3] = mat[3 * 4 + 1];
	SetVertexParm( RENDERPARM_TEXGEN_0_T, plane );
	RENDERLOG_PRINTF( "TEXGEN_T = %4.3f, %4.3f, %4.3f, %4.3f\n",  plane[0], plane[1], plane[2], plane[3] );
	plane[0] = mat[0 * 4 + 3];
	plane[1] = mat[1 * 4 + 3];
	plane[2] = mat[2 * 4 + 3];
	plane[3] = mat[3 * 4 + 3];
	SetVertexParm( RENDERPARM_TEXGEN_0_Q, plane );
	RENDERLOG_PRINTF( "TEXGEN_Q = %4.3f, %4.3f, %4.3f, %4.3f\n",  plane[0], plane[1], plane[2], plane[3] );
	renderLog.Outdent();
} else if( pStage->texture.texgen == TG_DIFFUSE_CUBE ) {
	// As far as I can tell, this is never used
	idLib::Warning( "Using Diffuse Cube! Please contact Brian!" );
} else if( pStage->texture.texgen == TG_GLASSWARP ) {
	// As far as I can tell, this is never used
	idLib::Warning( "Using GlassWarp! Please contact Brian!" );
}
SetVertexParm( RENDERPARM_TEXGEN_0_ENABLED, useTexGenParm );
}

 

was not stephen but brian ;) my memory might be more rotten than cheese ->

still glasswarp is not used in BFG atleast not in what goes for vanillas draw_common.cpp.

In BFG the file is called tr_backend_draw.cpp sorry for the confusion.

 

note ->

// As far as I can tell, this is never used

idLib::Warning( "Using Diffuse Cube! Please contact Brian!" );

and

// As far as I can tell, this is never used

idLib::Warning( "Using GlassWarp! Please contact Brian!" );

Edited by revelator
Link to comment
Share on other sites

Hmm... One possible way around this quagmire is to define an image map type for these types of effects. Call it a warpmap then just add warpmap stages to the material definitions in place of the ARB call. That fits the bill too since these effects already use a normal map as an input.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Heh im glad i make you smile :P

 

but...

 

 

No buts. Have you played Doom 3 BFG ? There is glass and there is warp it creates. All done using heathaze shader. I personally made glass in my game and it warps space behind it perfectly fine.

 

Unless we are talking about entirely different effects.

 

Maybe when they just started developing Doom 3 they had heathaze shader hardcoded and later on it migrated into ARB, but some of the C++ code remained ?

Edited by motorsep
Link to comment
Share on other sites

Tbh. i dont think the glasswarp shader ever had anything to do with heathaze, as far as i could see from vanilla it seems to have been an effect that did exactly what the name implied namely warping glass

windows etc. The effects in draw_common seem to have been an unhealthy mixup of old code some of which was newer used (Q3 leftover maybe). Rather confusing so mistakes here are probably common.

 

And yes i played it :).

Link to comment
Share on other sites

Must admit I don't fully understand the issue. I'm travelling this week so haven't done any more research on it yet. Are we thinking that the code in draw common isn't used? The heat haze shader program is commonly used, but that's the only one. I can only see 3 others used in just a couple of maps. How would a material activate the code in draw common? By using the texgen keyword or are there other ways?

Link to comment
Share on other sites

As far as i can see only a few of the effects in draw_common.cpp are used if you leave out the older backends that might have used it, pretty much only the code for skies and and maybe one other.

I just tried removing the code for glasswarp in revelation and it has no effect what so ever on heathaze hmm.

So yeah it looks like those effects have been moved to the shaders.

 

Might indeed be activated by a keyword in the materials, not sure which ill take a look later today.

  • Like 1
Link to comment
Share on other sites

Ok confirmed.

 

this ->

 

if (pStage->texture.texgen == TG_GLASSWARP) {
 // As far as I can tell, this is never used, confirmed revelator.
 glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, FPROG_GLASSWARP);
 glEnable(GL_FRAGMENT_PROGRAM_ARB);
 GL_SelectTexture(2);
 globalImages->scratchImage->Bind();
 GL_SelectTexture(1);
 globalImages->scratchImage2->Bind();
 RB_SetStageTexGen(surf);
 GL_SelectTexture(0);
}

 

is newer used :S the shaders are there but are not called anywhere in vanillas materials.

checked by disabling the code and using the warning from BFG, it newer triggers in any of the maps.

Not to say that the effect might be crap it might look cool even, someone better make a test map with a material shader using this so we can check it out :).

Mayhap the thing took to big of a toll on gfx at the time, vanilla was rather hard on gfx cards from back then so maybe they removed the interaction from the materials.

 

edit:

 

After some searching up and down the net i found out that its a refraction shader for windows, and it did work at some point but not in the last patch.

It was also disabled in Q4 but should apperently have looked quite nice when it was still working. Sadly i cannot find any hints as to why it was disabled.

Edited by revelator
Link to comment
Share on other sites

Digging deeper i found out that arbFP_glasswarp.txt arbVP_glasswarp.txt seem to have been the old shaders used for refraction but that functionality was moved to heathaze.vfp.

 

If the engine uses the arb2 backend only you can do

 

// a single file can have both a vertex program and a fragment program
static progDef_t progs[MAX_GLPROGS] = {
 { GL_VERTEX_PROGRAM_ARB, VPROG_TEST, "test.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_TEST, "test.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_INTERACTION, "interaction.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_INTERACTION, "interaction.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_BUMPY_ENVIRONMENT, "bumpyEnvironment.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_BUMPY_ENVIRONMENT, "bumpyEnvironment.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_AMBIENT, "ambientLight.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_AMBIENT, "ambientLight.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_STENCIL_SHADOW, "shadow.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_R200_INTERACTION, "R200_interaction.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_BUMP_AND_LIGHT, "nv20_bumpAndLight.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_DIFFUSE_COLOR, "nv20_diffuseColor.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_SPECULAR_COLOR, "nv20_specularColor.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_DIFFUSE_AND_SPECULAR_COLOR, "nv20_diffuseAndSpecularColor.vp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_ENVIRONMENT, "environment.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_ENVIRONMENT, "environment.vfp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_GLASSWARP, "arbVP_glasswarp.vp" },
 //{ GL_FRAGMENT_PROGRAM_ARB, FPROG_GLASSWARP, "arbFP_glasswarp.fp" },
 // additional programs can be dynamically specified in materials
};

 

those shader programs are not used anymore it seems, so far i had no adverse effects doing this.

 

the heathaze shader is loaded via the materials same as other effects, only a few like skybox and reflection depend on calling from draw_common.cpp

and those only because they need some support code from there.

 

I removed all the now defunct shaders for the other backends + glasswarp and vanilla still works just fine :)

Link to comment
Share on other sites

Digging deeper i found out that arbFP_glasswarp.txt arbVP_glasswarp.txt seem to have been the old shaders used for refraction but that functionality was moved to heathaze.vfp.

 

If the engine uses the arb2 backend only you can do

 

// a single file can have both a vertex program and a fragment program
static progDef_t progs[MAX_GLPROGS] = {
 { GL_VERTEX_PROGRAM_ARB, VPROG_TEST, "test.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_TEST, "test.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_INTERACTION, "interaction.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_INTERACTION, "interaction.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_BUMPY_ENVIRONMENT, "bumpyEnvironment.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_BUMPY_ENVIRONMENT, "bumpyEnvironment.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_AMBIENT, "ambientLight.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_AMBIENT, "ambientLight.vfp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_STENCIL_SHADOW, "shadow.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_R200_INTERACTION, "R200_interaction.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_BUMP_AND_LIGHT, "nv20_bumpAndLight.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_DIFFUSE_COLOR, "nv20_diffuseColor.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_SPECULAR_COLOR, "nv20_specularColor.vp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_NV20_DIFFUSE_AND_SPECULAR_COLOR, "nv20_diffuseAndSpecularColor.vp" },
 { GL_VERTEX_PROGRAM_ARB, VPROG_ENVIRONMENT, "environment.vfp" },
 { GL_FRAGMENT_PROGRAM_ARB, FPROG_ENVIRONMENT, "environment.vfp" },
 //{ GL_VERTEX_PROGRAM_ARB, VPROG_GLASSWARP, "arbVP_glasswarp.vp" },
 //{ GL_FRAGMENT_PROGRAM_ARB, FPROG_GLASSWARP, "arbFP_glasswarp.fp" },
 // additional programs can be dynamically specified in materials
};

 

those shader programs are not used anymore it seems, so far i had no adverse effects doing this.

 

the heathaze shader is loaded via the materials same as other effects, only a few like skybox and reflection depend on calling from draw_common.cpp

and those only because they need some support code from there.

 

I removed all the now defunct shaders for the other backends + glasswarp and vanilla still works just fine :)

 

This sounds like a good idea to clean up old cruft and remove the non-working or not-used-anymore shaders from TDM. The less stuff we have, the less can break and needs to be supported later.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...