Daggerfall Workshop Forums

Interkarma wrote:Cool! I'm using 5.2.2f1. If you would like to test, please comment out the below lines in GameManager.cs. It seems to be working on my test systems now, but I'm always happy for more feedback.

Edit: BTW, that bug only shows up in builds using non-exclusive fullscreen and the user selects a non-native resolution from the launcher. You will need to reproduce that to test bug. The result was the display was squished in the upper half of the screen. It does seem resolved in 4.2.2 however.

Fix verified!

I noticed today that the buildings seem to be floating above the ground a little bit, like not snapping to the ground completely:

CyberWilhelm wrote:

Interkarma wrote:Cool! I'm using 5.2.2f1. If you would like to test, please comment out the below lines in GameManager.cs. It seems to be working on my test systems now, but I'm always happy for more feedback.

Edit: BTW, that bug only shows up in builds using non-exclusive fullscreen and the user selects a non-native resolution from the launcher. You will need to reproduce that to test bug. The result was the display was squished in the upper half of the screen. It does seem resolved in 4.2.2 however.

Fix verified!

Awesome, cheers!

Phobos Anomaly wrote:I noticed today that the buildings seem to be floating above the ground a little bit, like not snapping to the ground completely

This isn't a bug. Buildings need to be raised a little off the ground or you end up with z-fighting on ground aligned structures like city entrances. Here's a static example, it's very flickery in game as depth buffer tries to work out which polygons to draw first.

It can probably be tuned a little further, but the depth buffer is sensitive to distance as well. So the more you move away, the more likely the problem will manifest. I have already tuned this about where I like it.

Daggerfall does exactly the same thing, you just can't notice as much because of the coarse resolution.

Oh, I see, false alarm then!

Phobos Anomaly wrote:Oh, I see, false alarm then!

Funnily enough, there actually was a bug related to this at one point which Nystul fixed. So it's always good to know, and I appreciate it.

Sometimes it's hard to tell the difference between a bug and something Daggerfall just did wrong (i.e. aligning polygons flat on the ground). It's all part of her charm though.

Vsync doesn't really seem to work in dungeons to well, setting it to 1 does nothing and 2 starts to lag, but both have tearing, no problems outside though and my chars. don't have gender issues anymore

GothwayBum wrote:Vsync doesn't really seem to work in dungeons to well, setting it to 1 does nothing and 2 starts to lag, but both have tearing, no problems outside though and my chars. don't have gender issues anymore

Vsync is a Unity renderer thing, it doesn't care if you're in a dungeon or not. I'd recommend just setting this from the INI, but if you do set from the console here are what the numbers represent.

0 = vsync off
1 = one frame of vsync (which is default, why changing it does nothing)
2 = two frames of vsync (which is why it lags)

I recommend only setting 0 (off) or 1 (on). More information in Unity manual.

http://docs.unity3d.com/ScriptReference ... Count.html

GothwayBum wrote:Vsync doesn't really seem to work in dungeons to well, setting it to 1 does nothing and 2 starts to lag, but both have tearing, no problems outside though and my chars. don't have gender issues anymore

In Linux build I've forced vsync in Nvidia driver, and now I get no screen tearing when Vsync is set to False in settings.ini, and a lot of screen tearing when Vsync is set to True (or if I call set_vsync 1 or set_vsync 2 in console).

It seems like core Unity engine issue.

Technical explanation for those curious about it: QualitySettings.vSyncCount sets GL_SWAP_INTERVAL to either 0, 1 or 2 - and it does more harm than good. Without proper calls to GL_SWAP_CONTROL and glFlush (or GL_SWAP_CONTROL_TEAR) it actually introduces screen tearing even if Vsync is forced in the driver.

It could be fixed in DFUnity, but in rather messy way, by setting vendor specific environmental variables. Let's hope that Unity engine guys will notice it and fix it by themselves in next engine releases.

Interesting analysis, thanks.