Revelator's TDM Branch

[revelator]

Checked out your changes and i can report that it needs a few fixes before compiling.

Also msvc 2013 is a complete nogo vanilla will newer work with it unless we change all the underlying functions to unicode (that will be a massive undertaking), the reason is that ms has removed multibyte support completely so all projects need to be unicode. I found something that might work though here http://www.microsoft.com/en-us/download/details.aspx?id=40770 this will install the removed multibyte support so that part should work again. There are also problems with vanilla being unable to find system headers such as windows.h and winsock2.h because the SDK paths are all wrong for msvc 2013.

Im working on it though and i hope to have the changes in soon.

[nbohr1more]

Hmm...

 

Well, I know my customLight changes would break compiling from experience but I was able to compile our own SVN

sources thanks to Greebo's recent changes so either "he did what you're suggesting" (commit log says otherwise) or

he's including other libraries \ components that negate this Unicode requirement?

 

Of course, I can't tell if this is an apt comparison with some of your other framework changes.

[nbohr1more]

OK, here goes one possibly dumb workaround. Include draw_common in draw_arb2 ... hope no local variable defines clash. Ha Ha!

 

I'm a little crazy if you haven't gathered yet

[revelator]

I can only guess that ms recently did some massive changes to msvc 2013 so be carefull when updating it, as they have stated that the old multibyte support libraries will be removed completely.

well i got it to compile but it crashes when loading any mission, btw do i need a new shader for the changes you made ? also i had to make some workarounds in draw_arb2.cpp as newstage is not defined anywhere the compiler refused to compile it. i fixed that by looking at the code in draw_common.cpp to see how newstage was defined, which btw left some questions as it seems to disable certain parts,

like ambient lighting. msvc2013 also needs recompiled versions of boost to be able to build darkmod, but if what you say is true i suspect greebo simply uses the 2010 toolset from the msvc 2013 interface.

[nbohr1more]

Yes, to use the the changes I made you need a material def with the "customLight" keyword and a defined "Program" (or vertexProgram, fragmentProgram pair).

 

I'll look at your changes because that's exactly what I just tried and failed at.

[revelator]

Ok i think i got it in working order now, while fixing this up i also moved the vertex and fragment programs for megatexture support out of material.cpp and into draw_arb2.cpp in the chain that looks for custom shaders. ill commit it in a bit.

[nbohr1more]

Thanks!

 

I saw that raynorpat did something of the reverse in his morpheus branch, he moved the shadow.vp bind to draw_common to be closer to

the other shadow code. Kinda neat not having to follow that ping pong between the two.

[revelator]

Aye i hate messy code besides we need a lot more code for this to work after having a look at rebb's chain for ambient light it seems we also need game code changes and ive done a few of the changes

now but the rest of the interface someone else will have to finish as im really bad with game code hehe.

[nbohr1more]

AFAIK, the game code changes are just for cvar toggling. Since this will be material defined there's no need as I can tell...

[revelator]

Hmm changes break the engine, not sure if its because im missing the shader but unless it finds the token "customLight" it should actually just skip over it but seems it does not.

Makes testing a bit hard tbh :S if you spot the bug feel free to make changes as you see fit.

Ill commit in a bit.

[revelator]

Hmm no there a bit more than cvar toggling to it as far as i can see it uses JC Dentons code for custom ambient lights, and theres a lot of code for it mostly by grayman. From what i can glean

it seems to use a table to make sure the ambient light values are keept in check so as to not allow silly values. Look for grayman #3584 in the code to see all the places where ambient light is parsed.

[SteveL]

Evening guys. The vc2013 changes are fine... I've been using it since July, although it wasn't till greebo fixed the light interaction bug in the Release build that we migrated the trunk to use it. You do need an extra executable installing for module for multibyte support in MFC, but there's an official Microsoft download: vc_mbcsmfc.exe . The new boost dependencies are now in the trunk.

 

Is the "customLight" change that you're discussing the one that'll enable a material to specify a different light interaction shader?

[nbohr1more]

"grayman #3584" that's for the AI visibility code. customLight shouldn't matter to that since it's just a boolean

to allow regular lights to use a different ARB program.

 

I see what you did there in draw_arb2... that is the traditional way of adding a new shader but wont allow mappers

to define their own in the material def. We either need to have the glbind look at newstage or use a brand new routine

to call the "glprogs finder" based on what's in the material def.

[revelator]

Ok i think i have something down that might do what you want without the game code changes.

 

Created a new function for using cubemapped light from textures, a bit like the ambient code.

new shader will use _custom def from light and the shader uses a customLight token.

[nbohr1more]

 

Is the "customLight" change that you're discussing the one that'll enable a material to specify a different light interaction shader?

 

Yes, it seems that the bind operation in draw_common doesn't work in draw_arb2 because draw_arb2 doesn't know what "newStage" is.

I tried to fix that but thus far have failed. At this point I probably should consider making my own architecture for that rather than trying

to use newStage but it was such a cool trick I don't wanna give up on it yet.

[revelator]

Hmm so you want this to accept a non prebound shader, oki not quite sure how vanilla handles that but ill see what i can find out about it.

Will probably require a lot more code than this i suspect.

 

Ok looked around and seems this is what allows non predefined shaders to be parsed from materials.

 

for (int i = 0; i < newStage->numVertexParms; i++) {
 const float parm[4] = {
  regs[newStage->vertexParms[i][0]],
  regs[newStage->vertexParms[i][1]],
  regs[newStage->vertexParms[i][2]],
  regs[newStage->vertexParms[i][3]]
 };
 glProgramLocalParameter4fvARB(GL_VERTEX_PROGRAM_ARB, i, parm);
}
for (int i = 0; i < newStage->numFragmentProgramImages; i++) {
 if (newStage->fragmentProgramImages[i]) {
  GL_SelectTexture(i);
  newStage->fragmentProgramImages[i]->Bind();
 }
}
glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram);
glEnable(GL_FRAGMENT_PROGRAM_ARB);

 

which btw is in the same function where you turned off processing things such as customLight.def

 

So if i understand this right the fix is simply removing

 

// prevent stage processing of ARB programs in customLight def
if (backEnd.vLight->lightShader->IsCustomLight()) {
 return;
}

 

and remove the code in draw_arb2.cpp ?

 

looking further this same process is used in material.cpp to parse definitions out of unbound shaders.

[SteveL]

"newstage" in draw_common means arb2 as far as I can tell, so that might be why draw_arb2 doesn't know about the label. Perhaps only "newstages" are passed to it. In my soft particle code in draw_common I combined the "old" and "new" shader stage code to draw any material texture using the softP ARB fragment program. It should be solveable. Where's the custom ight patch?

[nbohr1more]

Probably easiest to look at this in isolation:

 

https://github.com/nbohr1more/Doom3_divide

 

commits:

 

https://github.com/nbohr1more/Doom3_divide/commit/38e3e53c979caffad6afa4813fb3cd7c8df622dd

 

https://github.com/nbohr1more/Doom3_divide/commit/17fa900a9ddc0e2d066e2d58d241108cd8514faa

 

https://github.com/nbohr1more/Doom3_divide/commit/5a80bdbf6a74feb213680cd4b75d6e8d43003ab0

 

https://github.com/nbohr1more/Doom3_divide/commit/a7d3166dd7d48db249b72875dad1d555f7f3ce7f

 

 

I added that check:

 

// prevent stage processing of ARB programs in customLight def

if (backEnd.vLight->lightShader->IsCustomLight()) {

return;

}

 

to ensure that the stage processor wouldn't try to do a texgen with the source images and the defined

ARB. In previous experiments with adding ARB to light shaders, Doom 3 didn't seem to be smart enough

to distinguish them from surface materials. I would get too many indirection errors from my drivers indicating

that it was trying to process the material like a surface "newstage". That might've come in handy too but you'd

need to resolve the results to two output textures before it ever hit draw_arb2.

[revelator]

Urgh this will not be an easy fix, im running through methods of doing this but the only place that will likely work is by doing this early on in the interaction code.

Lights are done by precalculated constant registers which are a hard read as they are not exactly descriptive, but i think this one is for light -> OP_TYPE_LT.

Problem here is that to yank in custom light definitions it would need a rather hefty rewrite. We would need to replace those precalculated values by the ones parsed from the custom light shader instead.

This would also mean that any small error in the shader would crash the engine unless we can dig out a way to fall back to the precalculated ones in case it fails.

We also need to get the types for view origin / projection and falloff correctly.

 

My head is spinning from reading this

[revelator]

Hmm question what kind of lights are you intending to customize with this ? i had a look at the blendlight code and it might be possible to make a clone specifically for this.

Its also a rather misleading function as its called by fogalllights but has other uses than just fog. Its a bit of a weird one though as it blends 2 surface lights together so the other one would need to be

from the custom light shader.

[SteveL]

We use blendlights quite a bit. Fog, fake shadows beneath candle holders, patterns cast by stained glass, that kind of thing. They don't interact they just add another layer of colour to the surface by performing a blend operation on what's already in the colour buffer.

[motorsep]

We use blendlights quite a bit. Fog, fake shadows beneath candle holders, patterns cast by stained glass, that kind of thing. They don't interact they just add another layer of colour to the surface by performing a blend operation on what's already in the colour buffer.

 

Is fog lamp being blendlight as good as normal fog lamp, but with less performance overhead?

[nbohr1more]

I DID IT!!!!

 

   // nbohr1more: light material defs can now define custom ARB interactions
   if ( backEnd.vLight->lightShader->IsCustomLight() ) {
       const shaderStage_t *pStage;
       newShaderStage_t *newStage = pStage->newStage;
       qglBindProgramARB( GL_VERTEX_PROGRAM_ARB, newStage->vertexProgram );
       qglBindProgramARB( GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram );

 

Or, should I say "it compiles!"

[SteveL]

\o/

 

Although you might want to point pStage at something before you access its data

[revelator]

Darn i had a hunch that might be the case as far as i can see only ARB is passed to draw_arb2.cpp so that seems correct,

as for the custom light shader i would think we have to pull out the big guns to get that one working, all my attempts have failed miserably .

 

Looking at material.cpp we have foglights blendlights and ambientlights normally, while foglights and blendlights dont interact ambientlights seem to do so hmm.