over 4 years ago - /u/Darkimmortal - Direct link

NXT 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!

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by Dreadzone03

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%?

https://imgur.com/a/VzdFA62

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.

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by ben_g0

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

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by Dreadzone03

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 :)

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by TediousRS

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

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by _pod

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

over 4 years ago - /u/Darkimmortal - Direct link

Originally posted by [deleted]

[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