EU4 - Development Diary - 9th of April 2019

[Dunya]

Purely out of curiosity (I'm no programmer) but I would have always thought that as the number of tags decreases going into the later game (in most scenarios) that the stutter found in the late game would be reduced since there's not as many calculations? I just find it a little galling when I get to the last 20 or so years of a game and it starts to grind to an almost halt and capped out a core on my i7 9700k.

I think that the increase in the number of armies compensates that effect. Each big nation in the late game has to make more decisions (and probably more complex ones) than the sum of the smaller nations in the early game.

 

[grommile]

OK I think I am lost. What do you meant by SP lobby? Exactly?

When you click 'Single Player' on the title screen, the game history gets loaded and you are taken into a pre-game area where you choose what country etc. you want to play.

"Lobby" may not be the best word for it, admittedly, but it's the single-word term that springs most readily to mind for it.

 

[GundamMerc]

@The_sherbet game engine takes in account also dead tags that could spawn from their core provinces. Idk if it rules them out once they cant be released anymore, but i think not

Even if this is true, the amount of affect it would have on the game compared to other, more CPU intensive calculations such as the actual living AI fighting wars and such is rather minuscule. I wouldn't be surprised if this is one of those "common knowledge" things that turns out to be false or at most only half true.

 

[Fenxis]

This is something I'm studying right now in the university so I'll try to explain some issues that arise with multithreading (not sure were to begin explaining though ).

Even without deadlock the CPU cost of acquiring locks / synchronization can be quite high. Cache invalidation of variables loaded in CPU caches, etc. Lots of high performant systems have moved away from procedural languages+synchronization to functional languages and/or signal approaches.

Other considerations that will hamper multi-threading:
- debuggability
- calculations dependent on previous results
- calculations are independent but order specific

 

[Bravo555]

While we can't really apply the best fix to the issue (discontinue Windows support, the game just starts so much faster on Linux and MacOS, trust me), we managed to find some things we could do.

I take you're playing on Windows? NTFS (the way Windows arrange your files on your disk) is notably bad at accessing a lot of small files (such as our history files).
This is the main reason why Linux and MacOS starts much faster.
An obvious solution would be to put all core data in one big zip file but it's trickier than it sounds.

I don't recall a problem like this. Did you make a bug report?
Today's crash dumps are already pretty telling on what went wrong.
The tool itself will help for those edge cases where your game crashes but we can't find a reproducible way to trigger it.

Thank you for this post! I've been trying to figure out why Windows disk performance is so bad for some time now. Notably, when starting up Windows on my laptop with HDD 5400 RPM, after boot disk usage is at 100% for at least 15 minutes and it's just so infuriating! I noticed this doesn't happen when I have an SSD installed, which is obviously because accessing smaller files is so much faster on an SSD.
So, is entirely NTFS to blame regarding Windows' poor disk performance? Do you reckon if Windows had adopted any new, improved filesystem, would the situation improve?
Cheers!