Jump to content
System downtime for updates - Sunday 13 July 2025 ×
The Dark Mod Forums

duzenko

Active Developer
 View Profile  See their activity

  • Posts

    4159

  • Joined

  • Last visited

  • Days Won

    50

 Content Type 

Posts posted by duzenko

  1. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    Meanwhile, I've experimented a bit with glMapBufferRange. Changing the frame temp allocs in the VertexCache to that method is straight-forward enough, but it doesn't seem to have any noticable effect.

    Make sure that you're rendering a scene that is driver limited: GPU usage < 90%, r_showSmp is printing mostly dots.

    • Like 1

  3. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

     

    I'm seeing the same thing Cabalistic sees.

     

    With the "Enhanced Ambient" there is flickering and blown-out highlights. With the "Simple Ambient" everything looks just about identical to the ARB path.

    I brought the enhanced ambient glsl to the same color vertex method. Please test.

    I will try to look later today at the difference between arb & glsl ambients.

    • Like 1

  6. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

     

    The GLSL output is noticably darker, is that intentional? I find it a bit too dark, makes it difficult to see anything in unlit areas.

    No, I have been trying to port the interaction shader from ARB assembly, but there's still room for improvement. Can you send your screenshots with the difference?

    Is the ambient option set to simple or enhanced?

    I took the ambient shader from Pat Raynor's project and did not edit it yet.

    • Like 1

  7. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    Well, this is definitely a shader issue. Here is what I found so far:

     

    • the simpleInteraction in interaction.fs is fine and does not show flickering.
    • If you remove the R1*R2 addition to color in advancedInteraction, the flickering disappears
    • But if you output color just after the R1*R2 addition, there is no flicker in there.
    • If you remove var_Color.rgb from the final color calculation, the flickering disappears.
    • But if you output just var_Color.rgb, there is no flickering either.

    What?! Ultimately, a simple multiplication of two flicker-free color values produces flickering. Either this is a driver bug, or I just don't get it.

    Fixed the color flickering. The glsl mode is ready for testing.

  9. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  10. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  14. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  15. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  16. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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

  18. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    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.

  20. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

     

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

  21. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

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

  23. I'm working on a VR version - early alpha

    in The Dark Mod

    Posted

    @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
×
×
  • Create New...