nbohr1more

The ai_see spawnarg for lights allows mappers to attach a light to the player without affecting the lightgem. I don't recall seeing mention of that in the video.

Change to a higher soft shadow quality after starting your mission. For some reason switching missions breaks soft shadows. ( r_softShadowsQuality )

@Spooks Are you using single pass shadow maps? Disabling the single pass cvar should fix the missing AI and movable shadows.

As I recall, RGTC is just another name for Microsoft's BC4 or 5 This seems to confirm it: RGTC1_RED = BC4U, RGTC1_SIGNED_RED = BC4S, RGTC2_RG = BC5U, RGTC2_SIGNED_RG = BC5S

I set all TDM 2.07 settings to default and enabled postprocess then tried to eyeball the equivalent look in 2.08 With windowed mode and screens side by side. Here is what I currently have set: r_ssao_edgesharpness = "1" r_ssao_base = "0.1" r_ssao_intensity = "0.82" (tame darkening effect transition a little so ssao to non-ssao looks smoother) r_ssao_bias = "0.05" r_ssao_radius = "72" ( bigger radius has a richer effect but ssao=3 doubles this so if you use that mode set radius=36 ) r_ssao = "2" (less samples than 3 so less quality but better performance than 3) r_postprocess_desaturation = "0.05" r_postprocess_colorCorrectBias = "0.1" r_postprocess_colorCorrection = "5" r_postprocess_colorCurveBias = "0.95" (a little more contrast and brighter brights) r_postprocess_brightness = "1.0" r_postprocess_gamma = "1.22" r_ambientGamma="1.11" (compensate for gamma loss from color curve)

Yes, that is exactly what "SA" \ Share Alike means. You must "share" in the "exact same way" (alike).

This is how it works: NC == sell (we don't sell or do make any money from TDM) SA == or distribute any Content (modified or not) by themselves or in a texture pack, material, shader, scale modelling papers (pre-printed or digital), scrapbooking pack; The license from textures.com says you are allowed to share (distribute) within the context of a "full game asset with attribution" (model, map, etc). TDM distributes (shares) textures in the form of a full game package with attribution. Share Alike means that other projects can use TDM "game assets" and share them too as long as they also "follow these rules" (Alike).

The SSAO levels determine how far the effect spreads from the occlusion zones. They are presets that internally affect the base levels of the cvars so your cvar adjustments are relative to them. case 1: uniforms->maxMipLevel.Set(0); uniforms->numSpiralTurns.Set(5); uniforms->numSamples.Set(7); sampleRadius = 0.5f * r_ssao_radius.GetFloat(); break; case 2: uniforms->maxMipLevel.Set(MAX_DEPTH_MIPS); uniforms->numSpiralTurns.Set(7); uniforms->numSamples.Set(12); sampleRadius = r_ssao_radius.GetFloat(); break; case 3: default: uniforms->maxMipLevel.Set(MAX_DEPTH_MIPS); uniforms->numSpiralTurns.Set(7); uniforms->numSamples.Set(24); sampleRadius = 2.0f * r_ssao_radius.GetFloat();

Please experiment and compare to 2.07 You can also raise the r_ambientGamma to compensate for some of the darkening. Find a sweet spot with r_postprocess_brightness r_postprocess_gamma r_ambientGamma r_postprocess_colorCurveBias r_postprocess_desaturation

"Scalable Ambient Obscurence" Try lowering the r_ssao_base value to 0.3 or 0.4 (higher numbers are the cutoff to how dark it can be).

Bump. This is public now!!! Please engage with feedback

Now that I think of it, the major issue with our shipped shaders using makeIrradiance is that it wasn't quite compatible with the ARB shader. In 2.08 all ARB shaders are replaced by GLSL so that issue is gone. The only other concern is that makeIrradiance falls short in quality of a true irradiance image per the first post in this thread but mappers are free to create their own materials that don't use the keyword and bake their own irradiance textures per Spooks's recommendations. (I indicated to Duzenko that mappers would probably prefer that we simply make our shaders match quality to the external tool output but beggars can't be choosers and makeIrradiance still results in pretty nice ambient lighting.)

I hate to join the chorus of negativity but I honestly feel like Vulkan itself is a bad move. It pretends to be a modernized "clean slate" OpenGL but it really just encourages vendor lock-in since it is so closely tied to the hardware. It is mostly big industry players getting together and going "why do we need a flexible open standard when we are the only players left?" then collaborating on a standard that will only work for big industry players. The only thing I can say for it's defence is that OpenGL has been tainted by Nvidia's overwhelming ARB voting influence which has caused AMD to always be crippled in OpenGL performance. With Vulkan, AMD can equal or best Nvidia because they can force developers to write to their hardware directly. AMD is mostly behind this Vulkan push. They started things with their "Close to Metal" GPGPU initiative then developed Mantle then co-developed DX12. All these moves are addressing two issues at AMD. The aforementioned Nvidia control of the OpenGL standard and the fact that their driver teams are short staffed and less capable than Nvidia's. Why hire more OpenGL driver devs when you can get engine developers to write their own drivers via the Vukan or DX12 API? I can't fault it as a "strategy" but I'm not a fan of it as a standard. I guess PowerVR is pretty glad to see it too though. They also were living in the shadow of Nvidia's voting power in the OpenGL ARB and were happy to have a way to bypass that too (and even happier to offload driver development to engine devs).

Did you disable High DPI in Windows: https://wiki.thedarkmod.com/index.php?title=FAQ#Screen_is_Oversized_in_Fullscreen_Mode_.28Image_is_too_large_to_fit_the_screen_area_available.29 ?

Yes, that makes sense. We create a player entity flag then mappers can toggle the flag state with their script. And yes, I am well aware that using scripts to play with cvar settings is a bad practice but since the setcvar script event exists we should either make harmless by preventing it from archiving or remove it (presuming no mission uses it). So something like this wouldn't work? if ( LiveArchiveState ) { cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE ); } LiveArchiveState=true then provoke the "LiveArchiveState=false" during the Setcvar script event ? Of course, I guess there is that funny little issue of "thread safe..."?

The Newdark "patch" is a "replacement executable". If a Newdark "patched" T2 install works with no-cd on one system, it will do so on all systems.

Currently, the setcvar script command is not very useful in general due to this issue. Mappers have long wanted a way to do things like disable post-processing when under water or invoke other performance related cvars during outdoor scenes, etc. Most of these uses are obsolete now but there are still a few tricks you could do with this feature. Ideally, cvar changes called by script would not archive but that might be tricky to implement... The easy thing to do is create a non-archiving parent cvar that can be toggled by setcvar. I'll evaluate the cvar archive code and see if it's not too difficult to add a bypass feature there. Hmm... shouldn't be too hard to add a conditional here: Common.cpp // if any archived cvars are modified after this, we will trigger a writing of the config file cvarSystem->ClearModifiedFlags( CVAR_ARCHIVE ); Yep, and add a variable here: Script_Thread.cpp /* ================ idThread::Event_SetCvar ================ */ void idThread::Event_SetCvar( const char *name, const char *value ) const { cvarSystem->SetCVarString( name, value ); }

It is my understanding that Newdark is a No-cd executable and it is packaged in T2fix

I don't see a dedicated script event but you should be able to call setcvar to change this: scriptEvent void setcvar(string name, string value);

The "cv" append is internal code. In the console, setting: pm_swimspeed_variation 0.0 pm_swimspeed_frequency 0.0 should revert to the old swim behavior.

This is one stubborn issue. Every crude way I can think of to address it has failed. Forcing "reload models? No. Forcing SoftShadowsQuality to toggle after PlayerReady? No. I am inclined to think this is a driver bug. Maybe we exclude the secondary GL error check for Nvidia?

2 of the 3 audio devices have an Nvidia label. This is probably due to "Audio over HDMI" even if your monitor doesn't produce any sound. You may consider upgrading to Nvidia 442.59 drivers. It might improve stability. You can also try setting affinity so that TDM isn't running on core 0 and fighting with all your other background processes.

I think you can do "dynamic texture quality" with "partially resident textures" (aka GPU IHV spec megatexture tech). Though, Id Tech 5+ uses area flags in their maps to let the engine know "if you are near here then prepare to change quality when you get closer".

I've been tinkering with this issue by trying to bypass the GL error check in Framebuffer.cpp if the player isn't "ready" but no permutation of this has worked thus far. I think the other "quick fix" is to provoke reloadModels after PlayerStart is complete.

The specs say Analog Devices ADI (integrated) or Creative Sound Blaster Recon PCie (add-on) but TDM is only finding Nvidia audio: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'OpenAL Soft on Headphones (High Definition Audio Device)' OpenAL: found device 'OpenAL Soft on BenQ EL2870U (NVIDIA High Definition Audio )' OpenAL: found device 'OpenAL Soft on VX2457 (NVIDIA High Definition Audio)' OpenAL: using 'OpenAL Soft' OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.18.2 OpenAL: found EFX extension OpenAL: found 256 hardware voices I suppose you could try disabling Nvidia audio in Device Manager then enabling integrated audio in BIOS then update the drivers for that. I presume you have the "urgent" BIOS update applied: https://www.dell.com/support/home/us/en/04/product-support/product/precision-t7500/drivers ?