Playing Standalone

[Springheel]

I've copied my developer build to a folder outside the Doom3 folder to test playing TDM without Doom3. For my first test, I was able to load Chalice of Kings; the game started without any problems, but none of the lights were working. The lamps had the right texture and a glow particle around them, but no light was cast. I was able to walk around the lower level of the map. The torch flames looked a bit off...I think the heat haze is a D3 particle that needs replacing. Everything else looked decent except for the the lights.

 

I'm not sure why the lights aren't working though...didn't we replace the light textures with our own?

 

edit: Ok, at least some of the lights that aren't working have a texture of "lights/biground_candleflicker". TDM does have that texture, and it points to a valid .tga file:

 

  Quote

lights/biground_candleflicker

{

{

forceHighQuality

map lights/biground1

colored

zeroClamp

red ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm0

green ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm1

blue ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm2

}

}

 

 

What else is in there that could cause problems? Is "sintable" something that needs to be defined somewhere?

[grayman]

sintable is defined in base/materials/shaderDemo.mtr.

 

We don't have a replacement in the darkmod/materials folder.

[Tels]

If its a simple table of sinus values, we can easily recreate it w/o fear of copyright - after all, the output of the sin() function is everywhere the same in the universe.

 

Edit: I already added it quite some time ago to materials/tdm_tables.mtr, is this file maybe just not included, not there, or a typo in it somewhere? Or maybe it must be named differently so the table is loaded first?

[Springheel]

  Quote

sintable is defined in base/materials/shaderDemo.mtr.

We don't have a replacement in the darkmod/materials folder.

 

Isn't that the same table in tdm_tables.mtr?

 

  Quote

 

// sinTable and cosTable must be defined for the rotate function to work

table sinTable

{ {

...

...

 

From what I can see they're exactly the same.

[Tels]

Yeah the table should be there and loaded. Not sure what the issue is. Either the table is somehow not used, or the table isn't the problem.

[Springheel]

Here are some other errors from the console that might be relevant:

 

textures/sfx/vp3 stage with no image

 

image name "-" too short

 

couldn't load image _cookedmath

 

couldn't loadcube image env/gen2

 

Not all lights are not showing, however...I loaded up Thieves, and two of the electric lights seemed to be working properly. No flames are casting lights, however, and the world ambient doesn't appear to be working either.

[Shadowhide]

is there a chance that the some of the missions wont be working correct with standalone version because of script function missing ect?

[Springheel]

The good news is that I'm getting reasonable lists of missing assets when I load these maps.

[grayman]

  On 3/10/2013 at 3:20 PM, Springheel said:

Isn't that the same table in tdm_tables.mtr?

 

I didn't see it because the definition you quoted uses "sintable" and the new one is called "sinTable".

 

A case-sensitive problem?

[Springheel]

Tried changing it, but there was no effect.

 

In fact, I tried giving it an entirely different name, and as soon as I did the menus looked different, so it must be reading it. So it doesn't seem like that table is the problem. There must be something else.

[Tels]

  On 3/10/2013 at 11:16 PM, grayman said:

I didn't see it because the definition you quoted uses "sintable" and the new one is called "sinTable".

 

A case-sensitive problem?

 

No, definitions in D3 are case-insensitive. The original table was also called "sinTable" and used as "sintable" (or whatever one wanted).

[Tels]

  On 3/10/2013 at 11:45 PM, Springheel said:

Tried changing it, but there was no effect.

 

In fact, I tried giving it an entirely different name, and as soon as I did the menus looked different, so it must be reading it. So it doesn't seem like that table is the problem. There must be something else.

 

It is likely the GPU shader missing. The glprogs folder must be there (or actually, proper replacement for all of them), or some shaders won't work. Light falloff f.i. is done via pixel shader.

 

 

The "-" image name too short error is wrong, sometimes D3 complains that "some-image-name-here" is "some" and "image-name-here" and "-" and then warns about loading one of these (or all), but in reality, it just loads the image just fine. One of these annoying wrong warnings, and so far we haven't found out where it actually comes from.

[Springheel]

  Quote

The glprogs folder must be there

 

I copied all the missing files from Doom3/glprogs to our folder, but it didn't change anything about the light.

 

If it's helpful, regular, default lights seem to work. Nothing that uses a flame, however, whether candle, torch, etc, casts any light. And while normal ambient lights appear to work, the world ambient does not. The player lantern works normally.

 

I've made a tracker entry for this, as we won't get far with a standalone version without it.

[nbohr1more]

Maybe something has gone wrong with pk4 override for lights?

 

Did you try making a custom shader with a new light texture path?

 

Eg:

 

 

 

lights/thedarkmod/biground_candleflicker

{

{

forceHighQuality

map lights/thedarkmod/biground1

colored

zeroClamp

red ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm0

green ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm1

blue ((.05 * sintable [(time * ( 2 + Parm3 ) ) ]) +.95) * Parm2

}

}

Edited March 11, 2013 by nbohr1more

[Springheel]

This is with a version completely decoupled from D3, so there's nothing to override.

[nbohr1more]

Hmm...

 

I wonder if the lights/biground1 texture is damaged, RLE set incorrectly etc?

 

 

As for:

 

  Quote

 

textures/sfx/vp3 stage with no image

 

image name "-" too short

 

couldn't load image _cookedmath

 

couldn't loadcube image env/gen2

 

 

These will need to be fixed to the Enhanced Ambient to work.

 

The image_cookedmath is derived from the completion of the shader operations AFAIK so that wouldn't need to be replaced per se.

env/gen2 is needed for the directional ambient shading on the normals.

textures/sfx/vp3 may also rely on env/gen2 ? or image_cookedmath... hard to say without a condump.

 

I will have to try this myself....

[New Horizon]

  On 3/11/2013 at 10:17 PM, nbohr1more said:

Hmm...

 

I wonder if the lights/biground1 texture is damaged, RLE set incorrectly etc?

 

 

As for:

 

 

 

These will need to be fixed to the Enhanced Ambient to work.

 

The image_cookedmath is derived from the completion of the shader operations AFAIK so that wouldn't need to be replaced per se.

env/gen2 is needed for the directional ambient shading on the normals.

textures/sfx/vp3 may also rely on env/gen2 ? or image_cookedmath... hard to say without a condump.

 

I will have to try this myself....

 

The 'Enhanced' Ambient is no longer the one that uses the cooked math. We had three versions of Ambient before.

1. Simple - texture based and only used the diffuse.

2. Normal - refers to the interaction and ambient interaction shaders for the ambient lighing

3. Enhanced - texture based but uses diffuse, normal and specular passes.

 

After Rebb properly fixed the interaction shader and split ambient into it's own vfp file, the third option became obsolete since it was essentially emulating option 2. With Rebb's fixes, option 2 was faster. As far as I know, the cooked math was only used for option 3. So I don't know if we need to be using it anymore, although something tells me the HDR-Lite system may use it.

[Tels]

  On 3/12/2013 at 12:39 AM, New Horizon said:

The 'Enhanced' Ambient is no longer the one that uses the cooked math. We had three versions of Ambient before.

1. Simple - texture based and only used the diffuse.

2. Normal - refers to the interaction and ambient interaction shaders for the ambient lighing

3. Enhanced - texture based but uses diffuse, normal and specular passes.

 

After Rebb properly fixed the interaction shader and split ambient into it's own vfp file, the third option became obsolete since it was essentially emulating option 2. With Rebb's fixes, option 2 was faster. As far as I know, the cooked math was only used for option 3. So I don't know if we need to be using it anymore, although something tells me the HDR-Lite system may use it.

 

Hm, we should investigate this, if we don't need the cooked math anymore, a whole lot of code can be removed.