Unbearable mid and late game stuttering/lag, Stellaris 2.3 AR (VIDEO)

[Jack Sparrow]

This game is basically unplayable for me now, I would prefer slower day ticks and less of this. (see video)


Basically, every tick of an in-game day makes the screen jump when you are moving around.


I have my system specs in the video description.


Thoughts? it can't be just me that this is happening to, I think I'm pretty much done with this game for now, I am so over spending 10+ hours of gameplay to have to scrap the entire thing which is a better alternative than forcing myself to play through this sort of thing.

--> https://youtu.be/zJ9Onebp4oI <--

[NeoG]

It has nothing to do with memory. It is an engine problem (other games that don't use clausewitz engine don't have this issue).

Looking for threads that discuss this issue:

https://www.reddit.com/r/Stellaris/comments/aan2ry/how_is_this_okey_10_years_into_the_game_on_big/

https://forum.paradoxplaza.com/forum/index.php?threads/stellaris-dev-diary-149-technical-improvements.1180597/

That forum dev post goes into more detail. I could not find the thread that proved that it was the way the engine handles calculations (single processor meme lol), but you can navigate teh paradox forums, search for "stuttering" and behold a pale horse.

While they are always improving it, as far as customers are concerned, the best thing we can do is get a better, newer CPU.

[kbmodigity]

well yes going to a 64 bit engine has a HUGE effect on memory. a 32 bit engine can only access 4 GB. a 64 bit can go up to I believe 8 TB depending on OS

[kbmodigity]

Well I cant get much better of a CPU other than going to a n I9 I just built this comp and for my processor I have an Intel i-7 7800X 3.5 GHZ,, that is running with a RTX 2080ti and 32 Gb of ram yet I still get massive lag

[NeoG]

Origineel geplaatst door kbmodigity:

Origineel geplaatst door corisai:

Multi-cores =//= 64-bit architecture. You can have even 8bit multicore CPU.

64-bit architecture theoretically a bit faster (longer commands per tact), but in reality it isn't matter in most situations (you need very specific calculations to notice some increase of performance).

So don't try to imagine anything - PDX devs already said that 64bit patch will offfer neglible performance output and they were right here.

P.S. Bugs that they can add / fix TOGETHER with 64bit patch is whole another story...

My point is that by going to 64 bit it should have allowed for way better use if any of multi core or even multithreading.

I agree with everyone else here though. I am playing a MP game with a friend and the lag has never been this bad. My point is that I was hoping for the complete opposite.

I have played MP sessions before, and the issue then goes from bottlenecks in the calculations per tick in a single thread, multiplied by the latency iterations between each player.

So, everyone has different computers and they work at different speeds. Fast forwarding a game that has a lot going on, and because of the n^n latency interaction, you very quickly run into de-sync problems - not so much if you are playing in the PDX devs LAN competition (where they beta test) that has no latency (ping between players and host) and good computers, but very much makes it unplayable when you have latency of up to 500ms (australia to UK) with players spread around the globe, in addition to a wide spectrum of computing power of player's CPUs (♥♥♥♥♥♥/old cheapos vs latest gen CPUs), so yeah.

It is an engine limitation. I am sure they are doing what they can to fix and mitigate it, but because it is an issue at the root of how the game engine (clausewitz) processes all calculations, I don't really hold out much hope until they release a new one (so yeah no fix for released games except getting better CPUs).

[NeoG]

Origineel geplaatst door kbmodigity:

Well I cant get much better of a CPU other than going to a n I9 I just built this comp and for my processor I have an Intel i-7 7800X 3.5 GHZ,, that is running with a RTX 2080ti and 32 Gb of ram yet I still get massive lag

The solution is to reduce single thread load per tick, which usually means playing smaller maps with less AIs and pops. Figure out a way to make it work that still leaves the game fun and not a 100hr stuttering slog session.

[kbmodigity]

We are playing on the smallest map MP allows. My friend is hosting though as he has all the DLC's and I don't. His computer is not as good as mine but it isn't a toaster. I would say we are playing half way across the country apart so its not like having a NYC to Australia game going on.

We have also played many many many games with him as host in the past but up until this patch the lag has never been this bad

[NeoG]

Origineel geplaatst door kbmodigity:

We are playing on the smallest map MP allows. My friend is hosting though as he has all the DLC's and I don't. His computer is not as good as mine but it isn't a toaster. I would say we are playing half way across the country apart so its not like having a NYC to Australia game going on.

We have also played many many many games with him as host in the past but up until this patch the lag has never been this bad

Hey, I fell you. It sucks. I have suffered endless session restarts because of network, de-syncs, crashes and engine issues with clausewitz. The more players the worse it gets.

I will say that all other things being equal, the newest/fastest CPU should be the host, and you should play at the speed that actually allows the game to be played - don't try to force FASTEST if it keeps causing problems.

As a suggestion, a few years ago, playing short 4hr games was actually viable, but you have to tweak the settings to work that way, playing on a smaller map with faster research costs, etc.

[kbmodigity]

And when I say lag, we used to normally play on fast and can still do things. But with the latest patch, if we are on fast I will get a literal 4-5 second delay if I queue something. It makes me wonder if I clicked it properly or not.

We have checked and on fast I do get a day or 2 out of sync with him. But why should this start now???? Things should be better.

We are now forced to play pretty much only on normal unless we are both in "waiting times" of waiting for pops to grow to fix economies or just need alloys or something, there we can be on fast but even then you will see the hiccups with fleets flying and all . If either of us need to do some clicking then we have to go to normal to have it somewhat OK

[NeoG]

Here, I found the thread, please update OP with it as it has the answer to all Stellaris stuttering issues:

https://forum.paradoxplaza.com/forum/index.php?threads/multithreading-in-stellaris-a-quick-performance-analysis.1138327/

OP by sharpneli (thank you for taht if you read this here).
"Improvement suggestions and conclusions:
The decision to put single threaded work of tick calculation in the same thread that handles drawing and input may not be the best decision. As that thread is already overworked. Instead of even trying to multithread that part of the code one could "just" rip it out into a separate thread. It would still be serialized but it would not contend with resources of the main rendering thread. It may not be easy to separate but it's way easier than trying to parallelize it, as the actual work doesn't change, just where it is issued. Just this would give massive perf improvement as so much time is spent on rendering due to DirectX. In addition minimizing sync points to once per frame would drop a bunch of weird stalls.

One possibility of how something like this could look: There is a single tick state that the rendering thread reads. It just consumes. The tick generating code reads from the previous tick state (that the rendering thread also accesses) and generates the next state. Once the tick is calculated you just flip so that the now fresh tick is being read by both. Only one sync point per tick instead of usual mutex lock hell.

The profiler also says that the code is pretty terrible for a modern CPU. Lot's of stalls, branches etc. But improving that would be just gravy. It may not even be possible as the game must be scriptable, and that is fine. The biggest single bottleneck now is how the work is issued, not what work is issued.

So to reiterate:
Non parallelizable tick code should be removed from the mainthread that handles rendering.

Get a programmer from there who understands these well enough to change it, or if you don't have or if the person prefers other stuff hire some other expert either as permanent or get a specialized consulting company to help. Latter may be a good choice as after the work is done you don't really need to look at it for a long time."

[kbmodigity]

Honestly, if anything, PDX needs to make a new engine. THis Clausewitz or whatever its called is too outdated and its not like PDX doesnt make enough money to make a new engine for the modern era.

If they dont I can see PDX falling behind to other companies that do update the engines and way thier games run to accomodate current computers. PDX will soon fall out of business becuase of said blunder.

[kbmodigity]

Origineel geplaatst door NeoG:

Here, I found the thread, please update OP with it as it has the answer to all Stellaris stuttering issues:

https://forum.paradoxplaza.com/forum/index.php?threads/multithreading-in-stellaris-a-quick-performance-analysis.1138327/

OP by sharpneli (thank you for taht if you read this here).
"Improvement suggestions and conclusions:
The decision to put single threaded work of tick calculation in the same thread that handles drawing and input may not be the best decision. As that thread is already overworked. Instead of even trying to multithread that part of the code one could "just" rip it out into a separate thread. It would still be serialized but it would not contend with resources of the main rendering thread. It may not be easy to separate but it's way easier than trying to parallelize it, as the actual work doesn't change, just where it is issued. Just this would give massive perf improvement as so much time is spent on rendering due to DirectX. In addition minimizing sync points to once per frame would drop a bunch of weird stalls.

One possibility of how something like this could look: There is a single tick state that the rendering thread reads. It just consumes. The tick generating code reads from the previous tick state (that the rendering thread also accesses) and generates the next state. Once the tick is calculated you just flip so that the now fresh tick is being read by both. Only one sync point per tick instead of usual mutex lock hell.

The profiler also says that the code is pretty terrible for a modern CPU. Lot's of stalls, branches etc. But improving that would be just gravy. It may not even be possible as the game must be scriptable, and that is fine. The biggest single bottleneck now is how the work is issued, not what work is issued.

So to reiterate:
Non parallelizable tick code should be removed from the mainthread that handles rendering.

Get a programmer from there who understands these well enough to change it, or if you don't have or if the person prefers other stuff hire some other expert either as permanent or get a specialized consulting company to help. Latter may be a good choice as after the work is done you don't really need to look at it for a long time."

Or like I said,, just mka e anew engine,,that will take years,, but it will have to be done eventually,, and should have been done a few years ago

[The Mastermage]

i have the same Issues and i run an I7 8700k there is not much more Improvement to that except for maybe a 9700k an I9(expensive) or an Xeon(What is even Price at that point)

[Palifront]

I have a Xeon E5 with 16 cores so the single processor bottleneck really hurts on my system. I am at the point where each day (tick) has a 2 second lag.

[Vyndicu]

Origineel geplaatst door Palifront:

I have a Xeon E5 with 16 cores so the single processor bottleneck really hurts on my system. I am at the point where each day (tick) has a 2 second lag.

Necromancy!

Anyways back to topic at hand. Not a lot you can do about it as it affects not just low-end CPU and mid-range like 1700x Ryzen.

Just having more core CPU speed help a bit.

Alternative, you could turn down numbers of AI and world density low at Galaxy generation.

There are some mods that supposably help out with performance if you are ok with using mods.

[Unclean af]

If I had known the game turned to this....I never had spent so much money for it. Seriously, this sucks.