I believe it's a bug in all capture programs then, not just OBS. When I make gifs with ShareX it's an issue as well. No other game seems to have this issue.
Sounds like it could well be us doing something unusual then, it is still in our backlog to look into again at some point
Improved mouse support is on the way in the next NXT update or so
Has anyone looked into the mouse cursors being super weird to capture/record? Various capture methods (game, window, desktop capture) tends to either make the mouse cursor not appear at all, appear very far offset from where it actually is, or have a bunch of black artifacting all over it.
I believe we did look into this and determined it was a bug in OBS, but that was years ago so I could be wrong
Improved mouse support is on the way in the next NXT update or so
It is somewhere between your 'minimum' and 'perfect'. It cannot behave the same as a desktop mouse due to fundamental differences in the design of the mobile UI, and of mouse support on Android
awesome! thanks for your support!
I assume that means next week's update?
Not sure when the next NXT update will be, next week is a bit optimistic
The fix is already in the release pipeline for the next NXT update
[deleted]
UI scaling isn't possible on windows/mac either at the moment, but they transparently scale up applications that do not support scaling. I understand it is possible to do this manually on Linux, e.g. https://github.com/kaueraal/run_scaled
does droping java support means you will finally fix linux version of nxt?
the instructions on website how to install it are out of date for years and only cover ubuntu based distros
sure the client can still be installed with some workarounds but i think you shudnt need to manualy install out fo date libraries or use unoficial repacks of client...
The issue with out of date libraries will be resolved with this upcoming update
There are no plans to expand official support outside ubuntu/debian
will you finally update the ubuntu repository so we can play on NTX with newer ubuntu versions?
That is due to be released with the next NXT update
That is not rendering correctly, what phone do you have?
Thanks for the error log, that appears to be the same as a rare obscure crash we see on Android. Does it still crash if you enable the 'Global Mute' option in the ingame audio settings?
The A3 does not have enough RAM, your crashes will be due to running out of memory
If I am reading the specs correctly that tablet has 1GB of RAM? That is not enough to run mobile as things stand, your crashes will likely be due to running out of memory
Read moreHey dude, thanks for getting back especially out of hours.
The card is a 1080ti
Driver 436.60, although this has happened in 3 or 4 prior releases at least
OS is Win10 Pro, ver 1809, build 17763.805.
Normal mode
VSync off, The FPS caps are set to 150, but I also have RTSS capping the FPS of all apps to 144 because I'm running GSync.
I don't see any other instability with any other games on this PC, it's really stable otherwise. If other games crashed I wouldn't be blaming this on RS.
If you want me to test out anything else or have any other ideas please shoot - I'm happy to be a lab rat for the purpose of fixing this. The only annoyance is that the issue is spontaneous and not immediately reproducible.
*Edit:
I'm glad you mentioned driver cra...
RTSS = rivatuner statistics server? It has known issues with many games, we've actually had to hack in workarounds specifically for it, would recommend trying with it uninstalled
Sounds like a GPU driver crash, which is not something that games tend to recover from. Software that doesn't use the GPU or that is built to be super resilient to that kind of thing (browsers, Electron apps) will survive as you have seen
We test very extensively on Nvidia, not seen anything like that
Some questions:
Overall I would say this is likely a hardware issue. Are other games that max out your GPU stable on your hardware?
The 'overrun of stack based buffer' and error code are largely meaningless, it's just a generic error and something similar will appear for most causes of crashes in nxt. Other reports of this error a...
Read more[deleted]
I'm referring to the process of submitting commands to the GPU driver, and to the CPU side work done by the GPU driver to prepare that work to be executed on the GPU
Of course we use the GPU for rendering, but there is a significant amount of CPU work involved in submitting a frame to the GPU for rendering, we are looking to parallelise this
How about the updated dependencies for the Linux client? I understand that task isn't as high up the list but it really shouldn't take this long.
It's finally in the release pipeline, should be out in the next nxt update or so
It's a large set of changes that I believe fixes all the shortcomings of the Linux client (eg audio crackling, launcher not disappearing) in one go, if all goes well. Also a lot of work was put into outright removing or adjusting dependencies to avoid the same situation happening again in newer debian/ubuntu releases
Speaking of which will DoF ever be released?
Yes, some unforeseen issues came up, but it shouldn't be too far away. As always I can't promise anything
I am glad its being worked on. Do you have an eta on when we can expect this multi threaded change to occur or is it still very early in development?
I can't say as to when (or if) it might be released. There is still a mountain of testing and finishing touches to be done. It's looking good so far though :)
I once looked at the code of the java client as I'm interested in how games work, and I noticed that it seemed to calculate a lot of transformations (such as model scaling, rotating, etc) on the CPU. Does the NXT client still work like that, or does it now offload the calculations to the GPU like most other games seem to do?
(not intended is a criticism about your engine design, I'm just interested in how it works)
Yes that's all on the GPU in NXT, can't say as to whether that was true for the Java client. Everything in NXT is pretty industry standard
i Turned off every other program other then RS to get as accurate a screenshot as possible. now there are still background processors that cant be turned off and that is unavoidable. However if what you say is true then it looks like loading, shader compilation, particles and more ( disk IO and Audio) at most only utilise 1-10% of each thread while the main thread hovers around 80%, i guess what i m trying to ask is, what aspect of the game currently that is in that 80% single thread that is can't be changed to run in a multi threaded workload instead? I understand that RS as a game would inherently never use more than a handful of cores, but surely it can use more then 1 thread at 80% and 15 threads at 5%?
Most of the things I listed are quite heavy, and therefore beneficial to be multi-threaded, but only relevant during loading. You wouldn't see much work done by background threads while standing still with not many players around. In that case, we are left with particles, audio, a couple of other minor system and maybe some GPU driver threads, which are all lightweight, hence the numbers you are seeing. If you look at the graphs while initially loading the game, you should see much more thread activity.
The remaining main thread work is basically everything else. A good proportion of it is rendering, which is why it is next on the agenda to be multi-threaded. I believe we are also looking at multi-threading of animation. It is a gradual and complicated process to retrofit any multi-threading to an old game.
devtrackers.gg
