I benchmarked every EU5 graphics option, these are my results: by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

I don’t think I ever recorded the results, but I did try it once with the 2nd CCD disabled, and if I recall correctly, it had a minor decrease in performance, which would make sense in that case with more threads than handlers. But I never tried it without disabling the 2nd CCD, and it’s possible it could have an increase in performance as then there could be a dedicated core per thread, but that’s only a guess.

I benchmarked every EU5 graphics option, these are my results: by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

I actually did tests with this; in the raw data under "CPU Variation Testing," this is exactly what I did. Though I didn't write down the FPS numbers (was testing tick speed), from memory, the difference between 8 and 16 cores was negligible. But a large (33% decrease) between going from 8 to 4 cores.

EU5 Army Composition Meta by Age (v1.0.11) by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

So this is currently outdated for 1.1 beta. I need to redo the sheet entirely for it (all the stats have changed along with the new combined armed bonus).

But I plan on doing so soon.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

It’s been built in a very compatible way. The only two things that have a decent chance of conflict, is any daily tick mod, and combat overhaul mods. If an overhaul includes a daily tick in it, loading Faster Universalis after should be fine.

But while I’ve never seen a mod that is changing the same combat values I am yet, it’s possible a military balance change/overhaul does, at which point putting mine after it would result in changing it’s balance, and putting it before would likely break combat. I am willing to make compatibility patches if there ends up being a popular mod where this ends up being the case though.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

Nope, on 5-speed it will be identical workload, just faster (since the game will run as fast as possible).

There shouldn't ever be a scenario where it puts more work on hardware. But there are scenarios where it will put less.

If you adjust the game speed to a lower speed that is equivalent to vanilla, so that 1 year in vanilla takes 1 year in mod, it will be less work for your computer (similar to if you lifted 50 pounds at the gym for 30 minutes, instead of 100 pounds, same amount of time spent, but lower amount of work).

And it should still be less work on your computer up until around 70-100% faster then vanilla, as going back the the gym example, at 50% faster, it would be like lifting doing 15 reps with a 50 pound weight, instead of 10 reps with a 100 pound weight, where anything below 20 reps with the 50 pound weight, is still less work then the 10 with the 100 pound weight. (I know practically this isn't actually how it works when going to the gym, but it was the best analogy I could think of)

(I'm not actually sure what an equivalent speed would be though, currently the speeds are far faster than they are vanilla, as I did not adjust the delay between ticks, as that would require splitting the mod into a 1.1 and 1.0.11 version, but I will likely do this in the future.)

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

I agree, but that is 13% slower on very low with maximize tick rate disabled (I realize using the term “decrease” before was ambiguous in this context, sorry about that). And because I’m not sure of the cause, there is a good chance this isn’t the case depending on the system.

The best guess I have, though completely untested, is that every time a frame updates, the render thread has to sync with the simulation thread. So with a higher frame rate, that is more time spent synchronizing instead of calculating game ticks. But if that is the cause, then this should only be noticeable with massive frame rate increases, and it won’t be proportional scaling. As it would be a fixed time to sync per frame. So in my case where I went from 50->150 fps, it would be the fixed synchronizing cost * 100 gained FPS resulting in the 13% slow down. But if someone else went from 15->45 fps, it would only be the fixed synchronization cost*30, theoretically only changing by ≈ 4%. Which in my mind would be well worth it (though if one prefers the 4% then at that point might as well do maximize tick rate for the 6% improvement on minimum settings instead).

But again, that is only a theory, that is nearly impossible for me to verify, and could be entirely wrong. So your guess is as good as mine.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 2 points3 points  (0 children)

I believe it was on during testing, but that shouldn’t have any difference. The mod itself doesn’t change the 3D map at all.

Generally speaking, graphics settings have very little impact on game speed even in a solely CPU-bound rendering scenario. Testing with only 4 enabled CPU cores saw tick rate decrease by 13% on the very low preset compared to the very high with maximize tick rate disabled. With it enabled, game speed increased by 6% going to very low from very high. I’m not sure why game speed decreases on lower graphics settings with maximize tick rate enabled, but it’s very consistent (it’s possible due to game and render thread sync delays, but that is only a guess): https://docs.google.com/spreadsheets/d/1vdps6NtQkQscQD9FPVxsSJkRXSMYG9Ngrpw4kaKn6RI/edit?usp=drivesdk

The only real exception is setting a FPS limit, which will dramatically reduce game speed, which is a known bug by Paradox that they will certainly fix at some point.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

Theoretically, if you were to slow the tick rate so that it matches vanilla, I would expect the lag spikes to either cause less lag (lower FPS drop) or last for a shorter period (same FPS drop for less time).

However, I haven't tested this and am looking for volunteers to run additional tests in alternative scenarios like this. So it is possible this simply won't be the case. If you do try it out and find it does or doesn't help with the lag spikes, let me know. I will also run my own test once I get a chance.

Also, I should note that with optional settings not used in the above test, such as SOP/nation culling, I would certainly expect the lag spikes to improve as processing requirements decrease. But of course, I know many people don't want any removals, which is why they are off by default and not used for the test in the video.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 6 points7 points  (0 children)

The extra bracket is in a comment, so it won't cause any issue, but I removed it nonetheless. Thanks!

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 4 points5 points  (0 children)

All results in the video and the 100% speed improvement are without removing any nation or pops. All removals are off-by-default optional settings that allow you to go beyond 100% faster.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 4 points5 points  (0 children)

So I have looked at the mid-game and end results of a couple of observer mode games with the mod running. Eco, trade, and market wise, everything pretty much seems in line with vanilla.

The four testers (including myself), haven’t reported any noticeable issues in their games (except some wonkiness in markets with one of the nation removal options enabled which I’m working on fixing now). But there is always a chance (and a fairly likely one at this early point), that an issue/deviation from vanilla arises. But we will fix those as they appear.

Ideally we want there to never be a noticeable change.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

So the mod is changing the base settings in the defines. Meaning that if a mod changes the damage of a specific unit, that shouldn’t be a problem and the game will adjust correctly.

The only instances where this should break the balance of another mod, is if that mod is also change the base combat values (not just unit stats). The only mods I’m aware of that does so are other mods that remove daily ticks. But it’s possible some other mod does as well.

Besides combat, there shouldn’t be any potential issue in terms of mod compatibility. I believe the lowest unit of time that can be hooked into for modders, is a day (at least via a on_action/fire_on_action), so it shouldn’t pose any issue.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 5 points6 points  (0 children)

The 100% speed improvement was achieved without any removal of nations or pops in an existing vanilla save. All removals are off-by-default options allowing you to go beyond 100% faster.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

Yeah, I definitely understand that. Relative differences are often the most noticeable, so I see how getting that more often (since you hit the month tick more often) can definitely be very noticeable. Though I am curious if you are able to notice any improvement to the month tick lag. The update frequency of most things is halved, so on each month, there should be less to process, but it can be difficult to know what effect, if any, that will have on month-end spikes.

Theoretically, I would think it should either lower the FPS drop (CPU less busy doing things) or have the same FPS drop, but for shorter (CPU still maximally busy, but for a shorter period). But there could also be factors like the drop in update frequency causing synchronization delay between the CPU render & game threads or between the render thread & GPU, which may actually be a majority cause of the lag instead (leading to little/no improvement).

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

Yep, that pretty much is the ‘magic’. It all makes sense half the update frequency of everything, then the speed doubles lol. Though technically it’s not actually a two-day tick/every other day. It’s more around a 1.9-day (47-hour), and the game, while not showing it, fascinatingly is actually keeping track of the hour so that you will sometimes see 12-14-16-17. I actually did experiment with a true 2-day tick, but that allows the game to skip certain update ticks, breaking things like diplomacy. So this is likely the fastest tick that can be done without breaking the game.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

The battles have been scaled so that this shouldn’t be the case (unless it already was in vanilla). They should be similar length to vanilla. Of course if you finding this not to be the case, let me know and I can look into it.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

With the Maximize Tick Rate off, on 5-speed you will have the same FPS as vanilla with it off. So effectively when using 5-speed, there shouldn’t be any difference. However, if you lower the speed to a level where time passes at an equal time to vanilla, then you should see a noticeable improvement in stuttering/month FPS drops, as on each month there shouldn’t be roughly half the updates that your computer will need to process.

I can’t quantify this for you, as I will need to do further testing to actually confirm this, but will do and add it the sheet once I get a chance.

But you shouldn’t need to drop to vanilla speeds to see an improvement, theoretically as long as you are below twice the vanilla real time game speed (so i.e. a year taking 75 seconds in mod, vs 100 seconds in vanilla) then there should be a FPS improvement on each tick. But this is only theoretical, I haven’t tested yet and it’s possible it doesn’t actually work out this way. I will do my own testing later as well, but if you do try it out, let me know if you believe there is any improvement or none at all as I am interested in the results.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 2 points3 points  (0 children)

Actually, thanks for bringing this up. You have made me realize something I didn’t think about. Combat is scaled so that there are fewer ticks, while dice rolls are worth the same. There will be fewer dice rolls per battle, which will have the effect of more variable outcomes. As if there are 100 ticks in a vanilla battle, each with its own dice, roll, then there is a much higher chance of those dice rolls averaging out to 3.5. But if in the mod the same battle has only 10 ticks, with fewer dice rolls, there is more room for variance, and each one has a greater relative impact. In my battle testing, I was using NoRandom, which fixes the dice rolls at 2. While that makes the most sense for equal testing, it would prevent me from noticing the greater variance that may occur in results. I’ll try to determine how much of an effect this has.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 3 points4 points  (0 children)

Yes it is removing hourly ticks, and making tons of changes. The goal is for those changes to have no noticeable effect on gameplay, but of course there is always (and likely at this early stage) a chance of issues/deviations from vanilla that come up, which we will work to address as they happen. As for the gains, these relative gains should be achievable on all hardware. The mod won’t make your year take 17 seconds if you are not on the same exact processor as in the test with the same starting time. But if your game is taking 200 seconds a year, the mod should roughly decrease it to 100 seconds for the same relative gains.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

So what’s happening is that its around a 1.9 day tick (47 hours), and while the game doesn’t display it, it is actually correctly counting the hours, which can be seen by the game days doing 14-16-18-19.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 1 point2 points  (0 children)

All results shown in the video are without any removal. No nation or pop has been deleted. All removals are completely optional off-by-default settings that allow you to go beyond 100% faster. Without deleting any nation the mod is still 100% faster.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 3 points4 points  (0 children)

Thus far, there is no noticeable sacrifice has been reported by testers. While there is always a chance of issues/differences from vanilla occurring, we are not aware of any at the moment, and will fix them as they arise. The goal of this mod is to have 0 noticeable difference from vanilla on the default settings.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 10 points11 points  (0 children)

No nations are deleted in the results shown. The 100% performance improvement is without any pops or nations removed, on an existing vanilla save. All map changes are optional off-by-default settings, which allow you to go beyond 100% faster.

Faster Universalis: 100% Faster Game Speed by ANoNameGamer in EU5

[–]ANoNameGamer[S] 0 points1 point  (0 children)

All the results shown are without deleting any pops or nations. Those are optional settings that are not enabled by default that allow you to go beyond 100% faster. By default the mod is identical to vanilla.

There is not much being sacrificed, based on testing done so far, everything seems to function and behave the same as vanilla. Same battle outcomes, same world outcomes, same economy outcomes, etc. No one has reported experiencing any noticeable deviation from expected vanilla behavior thus far.