duzenko

nSight must work after you comment out the colorPointer call in the new glsl code. I spent a lot of time this year to get rid of the deprecated stuff with the exact goal to make TDM compatible with NSight. No idea how to use it though in this case. Yes, I meant the flickering problem that only happens on NVidia + glsl + enhanced interaction. It looks like it tries to use wrong memory as vertex data to me.

I fixed the crash on NVidia but shadows appear to be broken. Since this is nvidia only issue could you check if the fence sync causes it? I don't have a quick access to NV hardware (and AMD and intel are both fine)

it's a new console command to allow the tdm engine to run on two cpu cores

Maybe test the "com_smp 1" performance gain in svn exe?

Maybe try disabling vertex attributes in RB_GLSL_CreateDrawInteractions one by one?

No, it's actually test_direct.vfp. Sorry

That is probably correct because the assembly shader does this TEX localNormal, fragment.texcoord[1], texture[1], 2D; MOV localNormal.x, localNormal.a; MAD localNormal, localNormal, scaleTwo, subOne; No idea why they do that though. As for the xyzw/rgba thing, AFAIK they are supposed to be the same thing. None of the two shaders are mine actually. The assembly is from the previous TDM versions and the GLSL is from Pat Raynor.

interaction.fs vs interaction.vfp The glsl shader wins in speed 35:33, probably because it does not do an additional cubemap texel fetch. Throw that nvidia garbage out and get yourself a real GPU like the one I have (Intel 5500)

Actually they are not ignored, but the glsl shader somehow gives the normal map less weight in the output color. Can anyone look at both shaders and have an opinion which one is more correct?

Ain't I dumb! I replaced qglVertexPointer with qglVertexAttribPointerARB in TDM myself just a few months ago, and I have been staring at the qglVertexPointer in the glsl code for hours and didn't see it! It works now but bumpmaps are ignored for some reason.

Umm... I set r_ignore2 after map loads. Any crash details (stack trace, ...)? Fixed the missing qglProgramEnvParameter4fvARB for shadows in arb2 mode.

Can't see why support 2.1 when everyone is on DX10 hardware these days: http://store.steampowered.com/hwsurvey/videocard/.

I would try glMapBuffer + ring pointer writes Configurable buffer size would allow for 3+ frames of geometry.

Added the r_smp cvar. My wild guess about the glitch some have with smp could be related to vertex buffer use on a thread? If so we need to switch to permanent VB data pointer that must be safer in terms of thread sync.

You should now have full svn access? Could you add a switch to toggle SMP on and off?

r_customwidth 1920 r_customHeight 1080

Check for in game video resolution? And what is system wide screen resolution?

If only someone could just switch our system to one big vertex buffer...

The vertex cache is updated from frontend, not backend?

Best be left to Cabalistic after he's granted svn access?

Well, I don't know how to, so that ball is in your court. I would like that too but it might be the size issue? I'm new to the project myself. About the tic rate - when it is unlocked, it runs on the same rate as the renderer. I.e. if your system can squeeze out 90 fps then it's going to be 90 game tics as well. 120 -> 120, etc. If you want to limit it on top, use VSync. Yeah, it has been buggy, but since 2.05 most of those have been fixed. Right now I don't see the need to run game tics in parallel to frontend because my tests show the bottleneck to be either GPU or the video driver. The notable exception is spiders on complex terrain, but that's really rare. I can remember only two occasions on all missions I played.

There's backendGeo and frontendGeo now where just "geo" used to be in the surface struct. Now half the code is using the b.e.g. and the other one f.e.g. If we wanted to make it an option then we would have to do something like if (smp) write to backendGeo; else write to frontendGeo; every time.

Since nobody can be bothered to grant Cabalistic svn access I decided to spend a day and apply the above patch to trunk svn. (SMP only) A quick test shows about 21->27 fps raise in a particularly cpu-limited scene (the caduceus mission, wall corner looking at the tree and tower windows). Solid work, Cabalistic! Some thoughts: - no need to change tic rate from 60 to 90 since we now have the unlocked tic rate controlled by the com_fixedTic cvar - can't see why use glew - it compiles and runs just fine without it P.S. Since the threaded renderer requires changes in the internal draw structs I think we better just switch to it and don't try to make it an option. Otherwise we'd have to if-else every line that deals with them.

@cabalistic What was the base code version? I am trying to do a cumulative of your commits but comparing your initial commit to our 2.o5 source package I can see that yours is quite older. Here's the smallest .diff I could make: 140KB. Beat me if you can. https://drive.google.com/open?id=0B9OoHSmkeSeNaEh6blJYZjhiZkE