Search Unity

deployed build has graphics issues

Discussion in 'Editor & General Support' started by zumwalt, Jan 9, 2021.

  1. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    On rare instances, I am seeing graphics problems on computers with Spanish Windows OS installed, they have GTX 1650, GTX 1060, GTX2060 Video cards, now, with the Spanish Windows OS, those cards, the latest drivers, it appears the depth of field is resetting to 0, you can see the GUI but blue background, also, the GUI is not adhering to the anchors on the GUI, so GUI elements are way off, outside the bounds of the screen even.

    Has anyone ran across this?
    The game settings are initially set to the highest quality, I have given a UI to allow players to reduce there Graphix Resolution, but when they open the game, there Screen is set to 1920 x 1080 and they can't go any higher, but there desktop screen resolution is set to 2560 x 1440 and when a player first opens the game it is set to be full screen windowed, but it is ignoring there current settings. Even when they try to enhance it to another setting, these particular rare players can't change there resolution at all, others can use the menu to change the resolution, full screen option, texture level, and antialiasing.

    What is not working for these rare players is that they can't change there screen graphics resolution or full screen mode, they are stuck with 1920x1080 and full screen windowed mode.

    Why would Unity stop them from changing there resolution, why would it ignore the commands?
    I saw where the blue screen was about the depth of field being to close, and verified that will happen, but so far a vary rare set of players is experiencing this and so far it is only Spanish Windows OS with the problem What else should I be looking for?

    I have requested there DXDIAG info and waiting on a response from them, but was wondering if anyone else has experienced this issue.
     
  2. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    This is what the image should be and is for practically everyone:
    https://drive.google.com/uc?id=1GcMNCjSX3aXeV4TNMWhcDFD5Zlm5pYGy

    This is what the icons do on Spanish OS Windows 10:
    https://drive.google.com/uc?id=1FmjhOJu1wToZ70kFTjtHgLa9UpCwcYIu

    Notice the circles red, now, The X coordinate on spawning the location of the level icon is flipped and stretched away from its home spot for some reason, the Y seems normal, but the X goes from a + position to a - position. I literally only have 2 users, both using Spanish Windows 10 OS with this specific problem, I have not figured out how to fix this yet or understand why it is happening with GUI elements.

    Then there is the blue background problem on some levels, it is reversing the depth of field from a POSITIVE number to a NEGATIVE number,i mean like seriously, why?
     
  3. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    38,742
    I've not seen this before, but it seems perhaps either Windows is misreporting some important font or screen metrics in that locale, or Unity is mis-interpreting what the OS reports.

    I would start by looking into precisely what results in each of the items being positioned where they are, and by precisely I mean start from whatever the first number into the pipe is (anchor? position? width?) and work through it, printing each part out in the hierarchy until you understand which values are wrong.

    It may still be that you cannot fix it if the OS is giving you wrong numbers, but first you have to prove that is the case, then you can begin to develop a strategy to change the behavior.
     
  4. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    I have a code check in place if the depth is < 200 to make it 200, but from what i can see, it appears that the Camera GUI layout region height and width is being ignored or some arbitrary number, and in the game level, the blue screen means that maybe the camera, other than the UI, is literally not responding to the depth value, i am coming at this from every side that i can.
    Thanks for any pointers
     
  5. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    well after beating on this issue for at least a week, i had the players send me there player log files after i added a ton of debugging into it, and low and behold the problem, one of them, creeped up, for NON-USA players, the VECTOR3 is converting after stripping out the decimal place, for USA PLAYERS and most EUROPEAN players, it is keeping the decimal place:

    This is where i have the camera start information
    [camstart](-55,45.55,-140.57)

    This is how Unity translates it in a running game:
    Pos X -55, Y 4555, Z -14057

    Again, only in this instance for Spain and Argentina

    For European such as France, USA, UK, my players get it as
    Pos X -55, Y 45.55, Z -140.57

    So there is a core engine issue in Unity the last 2019 build
    This is a conversion done at runtime.
    I have the same issue with Vector2 conversion at runtime.

    So be aware of this in your Unity builds in Version 2019 LTS.
    do not use FLOATS when doing coded Vector3 and Vector2 conversions
     
  6. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    Actually to be more specific, I use :
    Resources.Load
    and i have a config file that i load that includes text file data in them
    now, these files have camera coordinates stored in them with decimal places
    apparently, with using the
    float.TryParse(value) where the value is the value from the text file that was in the resouse
    the result is returned to Vector3.x as example. as 13.55 from that countries float conversion
    Unity then sees it as 1355, but in some countries it is true as 13.55, other countries it was true as 1355
    the problem is the period, the text file is somehow being translated locally as UTF16 from Resource.Load where it should be UTF8, we have zero control over how Resources are saved and converted.
    The text files are saved as UTF8 files.
    Just something for others to be aware of, do not store vector 3 with decimal places in a file you load from Resources.Load, it will not work in all countries with Unity
     
  7. zumwalt

    zumwalt

    Joined:
    Apr 18, 2007
    Posts:
    2,287
    The lesson, the version of MONO that Unity uses is not universal, it has no idea that some countries use a period in a float while others use a reverse comma in a float. So when doing a Float conversion from a string value, you can't use the normal float tryparse and expect identical results in all countries. Unity itself is not country specific, so it works in many countries, but MONO is different in that the version we install in the USA may or may not be the same in other countries, that i do not know for sure, what i do know for sure is that if you store Vector3 or Vector2 as strings in your Resources folder in text files, you need to #1 make sure there are zero floating values, meaning nothing like 124.45, that will come out as 12445 to Unity in some countries, this test has been done many times now, even with the following code block added to my code:

    [RuntimeInitializeOnLoadMethod]
    static async void OnApplicationLaunch()
    {
    CultureInfo CultureEN = new CultureInfo("en-US");
    CultureInfo.CurrentCulture = CultureEN;
    Debug.Log($"Culteral Information Set to {CultureEN.Name}");
    }

    Which forces, upon application load, that the game see things as US culture. In some countries this now fixed the 124.45 and kept it as 124.45, in other countries, it still remained 12445.

    What honestly needs to happen, which i suspect is a major overhaul for Unity, is for the engine to understand the different forms of decimal places per country, but this is also a problem with the parsing, Unity utilizes MONO framework, so in essence, this is not a Unity problem but a MONO problem for a distributed game.

    My final solution, zero decimal places in the resource, and i do not mean .00 i mean non existent.
    So i just use, as example, 124 instead of 124.45, so if anyone else runs across this issue, at least you have a patch around it.