[I'm working on a VR version - early alpha]

It isn't. It happens before the main render on the main thread, while the frontend thread is idling. So basically, it's running exclusively.

 

Hm, unless it's accessing buffers that the frontend wrote to and are still syncing? That's the only thing I could think of...

Do the crashes go away if you disable com_smp?

[I'm working on a VR version - early alpha]

Don't think my GPU is ever even close to 50% in the Dark Mod. In any case, my primary interest in getting glMapBufferRange and the changes to static handling is that this will open up further parallelising the frontend.

[I'm working on a VR version - early alpha]

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. The problem, though, is that the engine also does a lot of "static" vertexcache allocations which are regularly freed again. The BFG engine doesn't even support freeing static vertexcache allocations, allowing it to do all static allocations on a single big vbo, which I'm sure would speed up the engine quite a bit. Unfortunately, the changes to support that are quite significant, and I don't think they are straight-forward to port. But I'll probably try, anyway.

[I'm working on a VR version - early alpha]

Ok, that seems to have gotten rid of the flickering

[I'm working on a VR version - early alpha]

The mod only supports SteamVR right now, so that is to be expected and a good sign, actually. Means it's working.

[Mass Effect: Andromeda is dead]

Unfortunately, it probably isn't that simple. Source code would only be useful with access to the underlying Frostbite engine, and seeing as EA has exclusive rights to that engine for their development studios, I'm fairly certain they have no interest to make it available to the community.

[I'm working on a VR version - early alpha]

@duzenko: Yes, assets are up to date. I also spotted flickering in the central training room just when I went through one of the doors. Might be related to portal change, or could just be coincidence.

 

Here's a screenshot of the flickering in the archery yard:

 

Comparison of the lighting. ARB2:

GLSL:

[I'm working on a VR version - early alpha]

Can confirm the color flickering is gone. Well done Not that I really understand the fix, given my previous observations.

 

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.

 

There is another flickering issue. In the training mission, if you head out to the archery range, the floor flickers with white color.

[I'm working on a VR version - early alpha]

Either should work. I have

 

set vr_enable 1

[I'm working on a VR version - early alpha]

None of the instructions worked. I get it in the headset but not a VR image.

As stated, the menu and other GUI elements are not adapted for VR, so you have to use your monitor to load a mission. Only there you will have a VR view.

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

Hm, I'm not sure, the vertex data seems fine. To me it looks more like the lighting or coloring is flickering. Perhaps some issue with shader parameters or precision. I'll try and see if I can narrow it down.

[I'm working on a VR version - early alpha]

This is not awesome. Give a dummy a direct link to VR. None of these links are intuitive or obvious.

Please keep in mind that this is nowhere near ready for prime time. It is more an impression of what might be rather than something you will enjoy playing. Also note that development is currently on hold because the engine has some severe performance bottleneck which need to be addressed before VR can really perform adequately.

 

 

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)

I just tested it. Shadows seem fine, but there is some general flickering going on, which seems to be related to lighting. The scene is also darker with GLSL than with arb2. The flickering does not go away if I disable smp, so is not related to the fence sync.

Has anyone gotten a graphical debugger to work with the Dark Mod? Those could really help track down these kinds of issues. But unfortunately, all I've tried (CodeXL, nSight, RenderDoc) don't work for one reason or another, but mostly because they don't seem to support the old profiles that the Dark Mod is using...

[Mass Effect: Andromeda is dead]

It's strange. Every single Bioware game I ever played was flawed in more than one way. And yet, all of them are among my favorite titles ever. Even though they always leave me feeling "this was great, but it could have been so much better", they resonate with me in a way very few other games do.

As flawed as Andromeda was, I still enjoyed it a lot. Shame they are abandoning it

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

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

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'm working on a VR version - early alpha]

Which shader specifically?

 

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

[I'm working on a VR version - early alpha]

Hah, I know the feeling all too well

[I'm working on a VR version - early alpha]

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?

[I'm working on a VR version - early alpha]

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.

[I'm working on a VR version - early alpha]

Applied my fixes to SVN. However, I have a lot of visual artifacts on SVN right now, due to the GLSL shader changes.

[I'm working on a VR version - early alpha]

Ok, thanks. I'll get the combined fixes to SVN

 

Probably won't backport any fixes to 2.05; as I said, I'm going to try to get some further engine improvements into SVN. Doesn't really make sense to do that on 2.05 anymore.

[I'm working on a VR version - early alpha]

@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

[I'm working on a VR version - early alpha]

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