Jump to content
The Dark Mod Forums

duzenko

Active Developer
  • Posts

    4149
  • Joined

  • Last visited

  • Days Won

    50

Posts posted by duzenko

  1. 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.

    • Like 1
  2. Yeah... no :) As much as I do not like Nvidia, unfortunately I always found good reasons to still go with them (so far).

     

    I had a quick look at the shader. One thing that surprised me is in line 33 in the normalize call, you are using wyz. Shouldn't that be xyz, or less confusingly, rgb?

    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)

    • Like 1
  3. They are the same thing, I just prefer to use the rgba accessors when accessing color values :)

     

    Hm, that is strange. I looked at a normal map in TDM, and it is clearly using the rgb channels, no alpha. Maybe I looked at the wrong one, or the texture loading modifies the channels. Curious, though. Shame it doesn't run on my side, or I could play around a little.

    No, it's actually test_direct.vfp. Sorry :blush:

    • Like 1
  4. Yeah... no :) As much as I do not like Nvidia, unfortunately I always found good reasons to still go with them (so far).

     

    I had a quick look at the shader. One thing that surprised me is in line 33 in the normalize call, you are using wyz. Shouldn't that be xyz, or less confusingly, rgb?

    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.

    • Like 1
  5. Which shader specifically?

    interaction.fs vs interaction.vfp

    The glsl shader wins in speed 35:33, probably because it does not do an additional cubemap texel fetch.

     

     

    Edit: The GLSL code path is still crashing for me, at the exact same place.

    Throw that nvidia garbage out and get yourself a real GPU like the one I have (Intel 5500) :D

  6. Thanks, that fixed the rendering artifacts.

     

    With an x86 debug build, if I start the game, then set r_ignore2 1 in the menu and then load a mission, it will crash when level load completed with an access violation (null pointer) somewhere in the Nvidia GL driver. The last line of code from the Dark Mod at which the debugger points is in RB_RenderDrawSurfListWithFunction at line 262. Context is drawing the lightgem, the triFunc_ according to the debugger is RB_T_FillDepthBuffer. I'm afraid it skipped a few steps in the backtrace there, because that can't be the offending line. But it is repeatable.

     

    If I set r_ignore2 to 1 directly in the autoexec.cfg, it fails right on startup somewhere when calling RenderSystem::EndFrame; again, the backtrace is incomplete, unfortunately.

    If I set r_ignore2 to 1 after level load, it crashes immediately, somewhere.

     

    Sorry that I can't really provide a good stack trace here. The null pointer exception in the GL driver might point to a null GL object being used, perhaps?

    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.

  7.  

    I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

    If you need a fence, there is no problem in using it via GL extension.

    Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

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

  8. @nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

    The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

     

    The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

    If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

     

    In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

    I would try glMapBuffer + ring pointer writes

    Configurable buffer size would allow for 3+ frames of geometry.

  9. @nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card :(

    Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

     

    Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

    You should now have full svn access?

    Could you add a switch to toggle SMP on and off?

    • Like 1
  10. Yes, but the structure has implications for both. For example, the backend spends a noticable amount of time binding vertex buffers, which the BFG edition doesn't have to, afaict. As such, I believe that the BFG version lowers costs for both frontend and backend, which is exactly what we'd need at this point.

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

    • Like 1
  11. Yes, exactly.

    The separation into f.e.geo and b.e.geo may be not necessary for non-threaded version, but it should not make any harm.

    I think we must have is a simple switch which quickly reverts the game to sequental version. This is very important in case someone meets some race conditions / driver incompatibilities / whatever.

    Well, I don't know how to, so that ball is in your court.

     

    So... have you ever though about truly opening development (including assets) and put everything on e.g. Github? I know that surrendering control is scary, but even if I had svn access, I'd still be in a dilemma. I can't really develop my VR version against svn if nobody besides the dev team can test that version. But developing against 2.05 is not ideal either, because it means essentially doing some of the work twice.

     

    When I tested the fixed tic rate, the results were not so great (on 2.05). Generally, since the tic rate cannot truly run parallel to the frontend, it still matters what tic rate you choose vs the targeted refresh rate. A tic rate of 60 means that for the VR version at 90 Hz, every third frame will not calculate a tic, but the other two will. Maybe it's not that noticable, but it might make physics calculations seem strange. So, for VR, a tic rate of 90 is better. Alternatively, you could lower it to 45 or 30. 30 is the only one that fits both 60 Hz and 90 Hz refresh rates, but I don't know if that might be too low?

    In any case, you certainly don't have to adopt the 90 Hz game tic, it's specific to VR :)

    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.

    • Like 1
  12. Nobody talks about putting every line from the diff into "if".

    Most likely, there is only one place really which makes everything work in parallel.

    The idea is to commit common changes (like structs changes) as is, but provide a switch that makes everything run sequentally if requested.

    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.

    • Like 1
  13. 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.

    • Like 2
×
×
  • Create New...