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
Hey 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 crashes - so I looked into Windows Event Viewer and I have matching entries timing with the crashes that essentially agree with your theory - "Display driver nvlddmkm stopped responding and has successfully recovered.". So it looks like it actually is a driver hang.
This leads me down 2 routes:
- 1) Why does only Runescape cause these and not anything else?
- 2) Should/Could NXT handle driver hangs more gracefully than this? I only studied graphics engines to a really basic level, but is the issue here literally that it's sending information to a hanging device for long enough that it causes the overflow? Could NXT have a longer 'grace' period before giving up on the device? I'll admit I'm a bit out of my depth on that point though.
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 are likely unrelated
EDIT: For others reading this answer only applies with the speci...
Read moreNXT uses multi-threading already in a number of places: loading, shader compilation, particles, and more. (As well as the essential areas like disk IO and audio)
Keep in mind many games have heavy CPU work such as AI and physics that don't apply to RS, so compared to them, we would inherently never use more than a handful of cores.
I'm currently working on multi-threading the rendering side of the engine, as seen in some other modern game engines. It's a pretty big engine overhaul, so likely a good way off, and can't make any promises. That said, early performance results on CPU-bottlenecked machines are looking good!
Read morei 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.
Read moreI 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 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 :)
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
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
[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
