rebb

Could setting the idMaterial::shouldCreateBackSides of the currently being processed surfaces to "false" work ? At least until FinishSurfaces() is done ?

Cool, so maybe the normals were never rotated the wrong way . Can you detect if there is a twosided material on a surface and switch according to that ?

Judging from the video it seems they are simply attaching a very faint blueish light to the player when his lantern is off.

Yeah it looks like the Depth-Hack is actually inverted when the LightGem is being calculated in the current frame. DeptHack -20 with interleave 1 looks like DepthHack 20 with interleave 0. That must be the reason for the flickering, while the FPS jumps are probably simply the game running faster between calculations, until it hits a LightGem calculating frame.

After testing this a bit, it seems like only particles with a Depth-Hack setting other than 0 are affected by the flicker-problems. Particles with Depth-Hack 0 work fine no matter which interleave value is used. However it seems like the default value of interleave 1 also affects depth-hacked particles. They don't flicker, but the Depth-Hack seems to be applied differently than it probably should, at least thats what i saw when placing a smoke particle system on the ground and switching interleave between 0 and 1.

Doesn't Fraps cap the Frame-Rate of the Game when recording ? Maybe the choppy movement is due to the high FPS fluctuation others are seeing, and the Fraps cap causes the fluctuation to not be as large as before.

The biggest problem with changing how light projections are applied is that all existing maps would most likely have to be redone so they still look and ( since TDM is all about the light or lack of it ) play as intended.

Maybe something could be piggybacked onto the Doom3 entity Dormancy-Tests, which is supposed to stop expensive entities from "thinking" when they are out of the Player's PVS. Maybe an extra entity keyVal that causes an entity to be removed ( or reused ) when going dormant. Altho that would probably require a map with good portal placement, to get the most out of something thats based on a PVS test.

Interesting, if these methods for scaling work, could this be used for scaling single models via an entity key-value ? Currently you have to scale models outside of the game ( not counting the rotation matrix "hack" that doesn't work properly ) - this could be a really useful side-product of LODE development .

The cinematics.def in Doom3 references skulltrail.fx, maybe it's worth digging around in those files.

Are you putting the bindto part in the "global" area of the fx declaration, as mentioned on iddevnet ?

The great e-googely says that it's "Tatev Monastery".

Are you doing "clean" uninstalls of the previous drivers before installing a new one ? Recommended routine : 1) Check the guru3D Forums for threads about most recent drivers, try to find the recent one with the highest "no problems, good driver"-type replies ratio 2) Download that driver 3) Download and install Driver Sweeper if its not installed already ( http://www.guru3d.com/category/driversweeper/ ) 4) Uninstall current Driver 5) Boot into Safe Mode and use Driver Sweeper as mentioned on the Driver Sweeper Link 6) Reboot normally and install new Driver Maybe it helps.

Maybe it would be a useful if the system allowed setting a certain random seed value per "LODE Node", so the positions are randomized, but still the same for a certain seed number. Would that be possible / make sense ?

Wonder if it would help to turn the patches into a func_static and somehow forcing larger bounds on the entity. Just a wild guess tho.

Is it possible that this skybox material accidentally got the ambient-light stages applied, while it shouldn't have them ? Try "r_showSurfaceInfo 1" in the console and aim at the skybox, it should show you the material name then.

That looks about right. Altho branching isn't really possible in standard ARB Programs. It depends on the hardware. Older cards like it better if things are simply done in some texture-lookups instead of more math instructions, while on modern cards its actually the texture-lookups that can be the main bottleneck.

You seem to be in a retro gaming bout lately - i get those too from time to time .

There are some visual improvements other than fixed ambient rendering, but not many, by and large due to pretty harsh "performance limits" being in place when it was developed - as opposed to 1.03, plus some instruction-saving changes that aren't actually visible.

That will toggle between default Doom3 look and 1.03 look, afaik - unless the shipped setup is different to what it was on SVN until shortly before release.

The visual improvements aren't actually cheaper than in 1.02, if you go by the shader instruction count - but there have been many other game-code fixes that have increased performance.

LoL ! Seems like a great winter-time disguise

That does sound pretty cool

It does disable doublevision effects, which are currently also used for the underwater blurriness. The underwater murk will still show up tho. It's just a temporary workaround that has shown good results for some people *eyes STiFU*.

Try setting "g_doubleVision 0" in the console as a workaround.