[0.10.25] Small lines in the graphics

[Ralzar]

I switched to 0.10.25 today and I' noticing these small seams in the graphics. Here is an example:
(You have to open the image at full size to see the small white dotted lines.)

linestatic.png (386.58 KiB) Viewed 1376 times

And here is the status window with a clearly visible line through it.

linestatus.png (134.59 KiB) Viewed 1376 times

I tried turning off all mods and reload the game. The white lines in the tavern was no longer there, but the status line still was. So this might be two different bugs and only one of them caused by a mod.

[pango]

The former is nothing new, it's been around for ages. I guess it's issues with the classic 3d models. It's usually inconspicuous, and depends on the exact position and direction of the view, that's probably why you didn't notice it before (but once you know what the problem looks like, you can see it almost everywhere).
Example from last February, not sure the exact version it was by then:

sentinel snow 2.png (985.97 KiB) Viewed 1351 times

The latter is linked to the upgrade to Unity 2019.4. I've looked at the code, Panel.cs, DaggerfallUI.SetDaggerfallPopupStyle(), etc. tried different things like turning off antialiasing, rounding coordinates, but for now I haven't found a fix...

[Interkarma]

I've mitigated the second issue somewhat in builds from 0.10.26. Please ignore issue in editor for now, or carefully resize game window until problem disappears.

At this time, I have no idea what has caused this texture scaling/alignment issue in 2019.4. My two suspicions are that it's an error in DrawTexture() or something changed with how new .NET framework rounds floating point values. The latter seems much less likely but needs to be tested.

I'll keep working on problem, and welcome help from Pango and others to increase understanding.

[pango]

My two suspicions are that it's an error in DrawTexture() or something changed with how new .NET framework rounds floating point values. The latter seems much less likely but needs to be tested.

Extremely unlikely in fact; The way floating point types behave has been defined with the IEEE and implemented "in hardware" in FPUs. Also, changing that would break all kind of software in subtle ways, I'd expect an outcry if it was.

[Interkarma]

I agree Pango, just thinking out loud as I do when something has no obvious cause. I can confirm rolling back to .NET 2.0 has no effect in any case, so that only leaves something in Unity itself. Our UI code for this hasn't changed in many years.

If no solution presents itself, my fallback is to re-implement DrawTexture() in some way and start picking around the problem. I'm don't have any more to offer at this point. I'm deep into the localisation stuff and this problem will need to rest in the back for a while.

[DigitalMonk]

My two suspicions are that it's an error in DrawTexture() or something changed with how new .NET framework rounds floating point values. The latter seems much less likely but needs to be tested.

Extremely unlikely in fact; The way floating point types behave has been defined with the IEEE and implemented "in hardware" in FPUs. Also, changing that would break all kind of software in subtle ways, I'd expect an outcry if it was.

Well, sort of. There are, I think, three rounding methods defined by IEEE 754, and the FPU can do any of the three based on what rounding mode it is told to use. Part of the difference is accuracy/precision-vs-speed, because truncation is faster than rounding and if that's "good enough" for you then the speed benefit may be worth it.

Annoyingly, this mode setting is somewhat global, being a register in the FPU. It _shouldn't_ cross process boundaries, because process switches should save/restore it. But if you're using a library in your process that just decides it wants the fastest possible floating point, well, when it sets that you get it too. And constantly changing mode isn't a great solution, because that switch is a little slow (not horrible, given that it happens on every process switch, but slow enough that you wouldn't want to just spray mode changes all over your code). I suppose you _could_ force the FPU back into the expected rounding mode just before displaying dialogs or other situations where the nature of rounding is important.

Take any details of the above with a grain of salt. I haven't explored this in detail in a decade or two. IEEE 754 definitely has multiple rounding modes and FPUs implement them all, but I'm less sure about the specifics regarding how many, how long it takes to switch, whether or not anybody ever switches any more, etc...

Side note: If a driver happens to use the FPU, that can be a problem because driver context switches aren't full process switches. _Shouldn't_ be a problem, because drivers aren't supposed to use the FPU in general, but still...

All of that having been said, it could also very easily be an issue of rounding (or texture boundary/clamp) behavior inside the texel/fragment/shader engine, either hardware or software. Since it changes between Unity builds (as opposed to "when changing video cards") this would be something about how the new Unity engine configures texture boundary behavior. When filtering a texture, the hardware must consider neighboring texels. At the boundary, it has a few options. It can assume a fixed background color, or it can repeat the texel it's on, or it can wrap to the other side of the texture. Repeating the current texel would allow for seamless/sharp edges as seen in prior Unity builds, while either other boundary mode could easily create the seams seen in the new engine.

[pango]

Well, sort of. There are, I think, three rounding methods defined by IEEE 754, and the FPU can do any of the three based on what rounding mode it is told to use. Part of the difference is accuracy/precision-vs-speed, because truncation is faster than rounding and if that's "good enough" for you then the speed benefit may be worth it.

Mmmh, that seems a lot more complex than I thought indeed.
For example I found this: http://blog.ygrenier.com/2017/10/dotnet ... -64bit-en/
TL;DR 32bit version of .NET 4.0 has different precision than the 64bit .NET version or C equivalent.
So that kind of stuff happens

But yeah, as you said that's still not the most probable root cause here.

[UnopenedCanofSpoopy]

My two suspicions are that it's an error in DrawTexture() or something changed with how new .NET framework rounds floating point values. The latter seems much less likely but needs to be tested.

Extremely unlikely in fact; The way floating point types behave has been defined with the IEEE and implemented "in hardware" in FPUs. Also, changing that would break all kind of software in subtle ways, I'd expect an outcry if it was.

Well, sort of. There are, I think, three rounding methods defined by IEEE 754, and the FPU can do any of the three based on what rounding mode it is told to use. Part of the difference is accuracy/precision-vs-speed, because truncation is faster than rounding and if that's "good enough" for you then the speed benefit may be worth it.

Annoyingly, this mode setting is somewhat global, being a register in the FPU. It _shouldn't_ cross process boundaries, because process switches should save/restore it. But if you're using a library in your process that just decides it wants the fastest possible floating point, well, when it sets that you get it too. And constantly changing mode isn't a great solution, because that switch is a little slow (not horrible, given that it happens on every process switch, but slow enough that you wouldn't want to just spray mode changes all over your code). I suppose you _could_ force the FPU back into the expected rounding mode just before displaying dialogs or other situations where the nature of rounding is important.

Take any details of the above with a grain of salt. I haven't explored this in detail in a decade or two. IEEE 754 definitely has multiple rounding modes and FPUs implement them all, but I'm less sure about the specifics regarding how many, how long it takes to switch, whether or not anybody ever switches any more, etc...

Side note: If a driver happens to use the FPU, that can be a problem because driver context switches aren't full process switches. _Shouldn't_ be a problem, because drivers aren't supposed to use the FPU in general, but still...

All of that having been said, it could also very easily be an issue of rounding (or texture boundary/clamp) behavior inside the texel/fragment/shader engine, either hardware or software. Since it changes between Unity builds (as opposed to "when changing video cards") this would be something about how the new Unity engine configures texture boundary behavior. When filtering a texture, the hardware must consider neighboring texels. At the boundary, it has a few options. It can assume a fixed background color, or it can repeat the texel it's on, or it can wrap to the other side of the texture. Repeating the current texel would allow for seamless/sharp edges as seen in prior Unity builds, while either other boundary mode could easily create the seams seen in the new engine.

FLDCW/FSTCW are considered legacy instructions (instructions used to change how the FPU operates for those unaware). Any software compiled within the last decade or so would be using the SSE family of instructions instead, and those don't have any particular instruction to change accuracy or mode of operation that I'm aware of. I'm pretty sure FLDCW/FSTCW shouldn't affect SSE instructions too, though I haven't written any code to test that or not.

[pango]

Rounding GUI.DrawTexture() rectangle coordinates seems to fix the issue (PR). It's still unclear why this is now necessary...