Jump to content
The Dark Mod Forums

I'm working on a VR version - early alpha


cabalistic

Recommended Posts

Hm, the flickering skybox is a puzzler. It does not go away even if I disable parallelism, and the correlation with the lightgem parameters almost make me think this has nothing to do with my changes.

 

Well, except I can't reproduce it in vanilla 2.05, so it has to be related to something I did :-/

In any case, I think this is a very different issue than the previous one. Looks almost as if some lighting or shader parameters for the skybox get mixed up...

Link to comment
Share on other sites

 

For system crashes, turn 0's to 1's since I'm not sure what's causing your crash.

It might make TDM run slower, but this is only temporary. Once the game crashes, post the darkmod.log file here.

Sorry for the late reply.

 

No worries. I've been tied up. I'll try to see about getting to this tonight. However, I'd like to mention that I also tried to enable EAX via this tutorial: http://forums.thedarkmod.com/topic/18249-tutorial-how-to-setup-eax-for-tdm-on-any-soundcard/

 

I also saw a crash on startup. However, it boots up fine now, though EAX won't work. I get the message telling me that I don't have the required hardware. In both of these cases, user error is definitely possible. I'm certainly not immune to making mistakes. However, it's interesting that both are audio related. I know the VR headsets do some audio-related magic & I wonder if there's a conflict. I should try disabling VR to see if either HRTF or EAX are working.

Link to comment
Share on other sites

@nbohr1more: I uploaded a potential fix for the flickering skybox here: https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.3

The issue disappeared for me when I moved the lightgem rendering after the normal backend rendering. It previously sat at an awkward position after frame start, but before normal rendering, and may have overwritten a few default settings and the back buffer selection command. Honestly though, I don't fully understand why it affected the skybox, specifically. In any case, let me know if this fixes the issue for you, too, and if you can find any further problems :)

  • Like 1
Link to comment
Share on other sites

Flicker is cured!

 

There are a few things like floating ragdolls at high FPS which have been cured in SVN via Blue_Pill's patches.

 

http://bugs.thedarkmod.com/view.php?id=4493

 

Also mantling in Swing can sometimes make you stuck inside geometry, same issue cured here:

 

http://bugs.thedarkmod.com/view.php?id=4435

 

And, of course, with high FPS your air supply in water depletes too fast (mentioned in the first bug).

 

Your decision to broach any of those issues in your 2.05 build verses just working in SVN nonwithstanding.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

If I set r_ignore2 to 1, it crashes on start. Setting it to 0 (which is the default and should disable glsl) has the visual artifacts.

Umm... I set r_ignore2 after map loads. Any crash details (stack trace, ...)?

Fixed the missing qglProgramEnvParameter4fvARB for shadows in arb2 mode.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

It works now but bumpmaps are ignored for some reason.

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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?

  • Like 1
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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
Link to comment
Share on other sites

I meant a normal map texture, not the shader :) The textures have rgb channels, and r and g are definitely relevant. So unless the texture loading somehow transfers the r channel to alpha, then using the alpha channel in that calculation just doesn't make sense to me.

  • Like 1
Link to comment
Share on other sites

There's a small block of biases

{ x, y, z, a }

which we multiply our normalmaps by at the top of test_direct.vfp. These are what make our normals look deeper than the standard doom 3 versions. I'll post more details when I get some PC time.

 

Edit:

 

Here is a better illustration:

 

Biases:

 

 

 
# Scale the normal map scale up by a factor of 1.5.
PARAM    subOne        = { -1.4, -1.4, -1.0, -1.0 };
PARAM    scaleTwo    = {  2.8,  2.8,  2.0,  2.0 };
#PARAM    subOneN        = { -1.0, -1.0, -1.0, -1.0 };
#PARAM    scaleTwoN    = {  2.0,  2.0,  2.0,  2.0 };
PARAM    half        = {  0.5,  0.5,  0.5,  0.5 };
 

 

Normal map load:

 

 

 
# load the filtered normal map
TEX        localNormal, fragment.texcoord[1], texture[1], 2D;
MOV        localNormal.x, localNormal.a;
MAD        localNormal.xyz, localNormal, scaleTwo, subOne;
 
  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I haven't been following this discussion very closely so perhaps this isn't terribly useful but reading the posts about ARB and alpha reminded me of an issue I encountered when creating a color grading shader. I noticed that after a texture lookup, red color data was being stored in the alpha channel. You had to swizzle the channels around to correct it like this ...

# do lookup
TEX low, lut_coord, texture[1], 2D;
TEX high, lut_coord_high, texture[1], 2D;
MOV low.rgba, low.agbr;
MOV high.rgba, high.agbr;

I never really looked into why. I figured I was doing something wrong but it could be a bug in the engine.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...