Linux issues reports

The next update will be available on Wednesday, December 18, in the early evening (GMT+1).

This update will not yet replace the Java version, instead it is the actual content update. We'll provide more information about the transition together with the update.

    Hi red51


    First of all, awesome!! I love the new graphics, and the ambience :)


    I'd like to report some issues I found in Linux (I am well aware this is a preview, but thought it was important to report)


    Setup: Linux Debian 64 bit, Steam version, Ryzen 1700x, Nvidia GTX 1700 with proprietary drivers 450.80


    - There is a lot of mouse lag, no matter the graphics settings I use. The graphics run well in very high, but lag from start moving the mouse to see it on screen is terrible, even if I use the lowest graphics settings (no change in the lag).

    - It may be related to the above, but when walking sometimes after a few (10+) seconds of very nice and smooth movement, it jumps forward

    - there are some graphic glitches in the menu (settings) as well as in the radial one. bits of them briefly disappear and appear again.


    Let me know if you need more info on my system, logs, or whatever :)


    Thanks Red51!

    Thanks for the error report!


    Quote from MarcosRC

    - There is a lot of mouse lag, no matter the graphics settings I use. The graphics run well in very high, but lag from start moving the mouse to see it on screen is terrible, even if I use the lowest graphics settings (no change in the lag).

    Hmm... not sure what could be causing this :thinking: We're using Unitys new input system which is still suffering from some issues, not sure if this is responsible for this... one thing you could try is to change the fullscreen mode (by default the game is set to fullscreen windowed, maybe change it to exclusive fullscreen [just called "fullscreen" in the settings]) and see if that helps?


    Quote from MarcosRC

    - It may be related to the above, but when walking sometimes after a few (10+) seconds of very nice and smooth movement, it jumps forward

    Does the game actually stop rendering (i.e. the screen also freezes), or does just the player get stuck? In the latter case, does the player still move (body motion, footsteps etc), so the player basically gets stuck, or does it feel like the input gets interrupted?


    Quote from MarcosRC

    - there are some graphic glitches in the menu (settings) as well as in the radial one. bits of them briefly disappear and appear again.

    This is unfortunately a known issue. It's caused by Unitys new UI Toolkit (to be fair, this package is still in preview and not production ready - but still much better than Unitys old UI). One thing you can do to slightly improve the situation is to open the config.properties file in the game directory and set Game_UILayersSmoothFade to false - this disables at least all fade animations. You will still see the glitches though... we have to wait until this gets sorted out by Unity.

    Hi red51

    Yes, setting to fullscreen was the first thing I tried, and it made no difference.


    The jumps forward are instantaneous, so there is no screen freeze (or maybe very briefly?). It just goes rendering nicely and suddenly you are a step or two ahead and keeps going from there.


    Attached a quick video (I had to make it low quality due to the file size restrictions in the forum)


    You can see there 2 things:


    The jumps: there are 2-3 of those


    The lag: all the turns happened noticeably after I moved the mouse, and as you can see the turns go like in blocks, not softly, is like it catches up with the mouse not turning anymore.


    untitled.mp4

    Could try to switch to NVIDIA 455.45.01 or disable Vulkan for a test. There's iirc some start parameter. Looks to me like GPU starvation and there are so many Vulkan fixes on each driver release nowadays.


    Cuz this works like a charm for me on Mesa 20.2.3 + Navi 10 (Radeon RX 5600 XT).

    I couldn't get the game to start at all initially, it was crashing with an error related to 'opus.so'. The fix for me was to copy the system file libopus.so from:


    /usr/lib/x86_64-linux-gnu/


    into:


    .local/share/Steam/steamapps/common/RisingWorld/_New Version/Data/Plugins/


    (Note the system file is libopus.so.0, I renamed the copy to libopus.so)


    Other than that no issues at all so far:


    MX Linux 19.3

    Kernel: 5.8.0-3-amd64

    AMD Ryzen 5

    AMD Radeon RX570 8gb

    16gb RAM

    Quote from vinehold

    (Note the system file is libopus.so.0, I renamed the copy to libopus.so)

    While this is not related to GPU issues I'd suggest that you symlink opus.so to your system's libopus.so.0 because this way you will not miss updates on that lib. Your system takes care that this always points to the latest version.


    This way you also prevent a broken lib in the future when other dynamical linked libs can no longer be found (see output ldd opus.so). May be unlikely in this case but best practise n stuff.

    Quote from beko

    While this is not related to GPU issues I'd suggest that you symlink opus.so to your system's libopus.so.0 because this way you will not miss updates on that lib. Your system takes care that this always points to the latest version.


    This way you also prevent a broken lib in the future when other dynamical linked libs can no longer be found (see output ldd opus.so). May be unlikely in this case but best practise n stuff.

    Yeah, I'm hoping that this Unity version of RW gets fixed for the proper release and therefore won't require any symlinks or manual tweaking. I'm keeping it sort of 'sandboxed' at present, hence the file copy/rename so it's easier to see what's going wrong.

    Thanks for letting us know MarcosRC ! I have to admit that we have no clue at this stage why there is such an issue with the mouse movement (and movement input in general) on some Linux machines. There was another user who reported the same issue on Kubuntu.


    It seems to be caused by Unitys new input system - in fact it's still experimental and far from being solid and battle-proven. In addition to that, Linux unfortunately does not get much love from Unity (at least their newer techologies - SRP, new input system, UI Toolkit etc - are having lots of issues on Linux) :/


    The problem is that most of Unitys code is black boxed - their source code isn't available. While parts of their new input system are written in C# and therefore available on github though, the native handling is still in their C++ code base (and therefore inaccessible)... as a result, issues like that are mostly out of our control :silenced:


    Is there any other input device connected to your machine? Do you own a gamepad? If you have a gamepad, you could maybe try if the same issues persist with gamepad input (at least xbox and ps4 controllers are supported right now).

    Quote from MarcosRC

    Hi red51 , I got back to the linux version, and tried both my Steam Controller and my XBox 1S controller (USB connected), both have the same lag as the mouse.

    Thanks for checking that out! It's good to know this issue isn't specifically caused by the mouse... maybe it's not related to the input system at all, maybe it's the delta time instead (which plays a major role for input like that) :thinking: Unity wrote a block recently acknowledging a few issues with their current delta time implementation: https://blogs.unity3d.com/2020…ameplay-what-did-it-take/

    It's still hard to believe the delta time is that inconsistent on some Linux systems, but who knows... Actually the 2020.2 tech stream just got released a few days ago. Maybe you could try out our next update and see if the issue still persists.

    If this is a delta timing issue running it on a single thread only may help. I remember that we used to do this with older games that could not deal with multiple cores at all. It's no solution but may point to the problem. See

    taskset for details on how to do this.


    I only seeked through that linked article but neither Linux nor Vulkan was mentioned once in the article. Huh?

    Quote from beko

    If this is a delta timing issue running it on a single thread only may help. I remember that we used to do this with older games that could not deal with multiple cores at all. It's no solution but may point to the problem. See

    taskset for details on how to do this.


    I only seeked through that linked article but neither Linux nor Vulkan was mentioned once in the article. Huh?

    Thanks beko


    I tried setting the Launch Options to "taskset --cpu-list 2 %command%"


    It did indeed work: no more mouse/input lag. Even some of the graphical glitches in the menu, while still happening, are much less noticeable.


    Of course, there is now stutter as 1 CPU struggles to run Rising World, but at least this may help red51 / Unity developers to address the issue?


    Thanks!

    Oh, that's an interesting result MarcosRC :wat: This really sounds like a delta time issue... another thing: did you enable VSync? Or did you explicitly enable/disable VSync in the NVIDIA driver? It looks like the current Unity version is suffering from a bug resulting in horribly broken delta timing if VSync is disabled in the driver, but enabled ingame :monocle:


    Quote from beko

    I only seeked through that linked article but neither Linux nor Vulkan was mentioned once in the article. Huh?

    The delta time issue seems to affect all graphics API, but it's true, they didn't mention Vulkan in this blog :thinking: According to Unity, this issue is only fixed in DirectX and Metal (and on Consoles) - the Vulkan fix was postponed to 2021.1 (which will be probably available in 4-6 months) X(

    I have tried vsync on and off and combinations on the driver and the game, with no changes, lag still there unless I set it to one core.


    I even disabled gsync on my freesync monitor, also with no change. :(

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login