Panos wrote: ↑Thu, 6. Jan 22, 17:17
4.20 had a general optimization on game perf including saving. On a 5900X with MP600 nvme drive now takes around 5 seconds to save on Windows 10, compressed, even a 70 hours campaign. That wasn't the case pre 4.20 which needed much more time.
I'm mainly playing on a 5900HS linux laptop these days, and I've encountered no such improvements.
The 49 second average I quoted was on 4.20, ~200 hrs on the current playthrough, ~90 MB compressed saves.
Looks like the last couple saves are in the realm of 5-8 MB smaller than 4.10 saves, but save duration's about the same.
I've got X4 saving to an external SSD atm, but disk I/O certainly doesn't seem to be the bottleneck.
Ehli wrote: ↑Thu, 6. Jan 22, 13:42
Sorry for sounding harsh...
S'ok, no kid gloves requested.
Glad you got the indignity out on the first shot
But hey, it's not about me, and it's apparent I'm not insulting anyone or trivializing the effort involved.
I'm just making a good-faith effort here on behalf of the player base to get some tangible answers after 3 years and, hopefully, some eventual results.
Ehli wrote: ↑Thu, 6. Jan 22, 13:42
- IMO the OP has way too little information of the X4 code to be giving out advise like that.
- You can't assume ECS, it's a custom in-house made engine.
- The suggested solution/github code is, IMO, a way too simplistic / is a blue-eyed approach and only shows a lack of understanding their core issue.
- ...a mutex eating well over 200 CPU cycles on a fine-grained level. Especially the getValue - even if you use a spinlock instead of a mutex you're performance is now guaranteed abysmal!
- The problem isn't serialization, the problem is consistency.
That's a nice list of things we already covered in this thread.
Appreciate the recap, so I won't bother addressing most of it again, save to say about #3 and #4:
- It was intentionally simplistic for a novice-to-intermediate audience -- it's a general example designed to use as a talking point... and it doesn't mention X4 anywhere in it
- Sounds like in your haste to post you skipped the second code sample
But no matter.
It's common in every passionate forum that no example is
ever good enough.
It's either too generic -- and apparently insulting to some -- or it's hyper-specific and shot down for not being reusable.
I believe the rest of your post could be summarized as
"I'd rather feign indignation on behalf of EgoSoft than allow any code-oriented discussion," to which I'll simply say that no one's twisting your arm to talk.
You're more than welcome to snap those big boy suspenders you seem to be so proud of and tell us how it's done if you'd like to contribute.
Reiterating how it's
not done, however, is not constructive without counter-suggestion.
Point is, the issue keeps coming up.
Maybe you don't like it. Maybe Imperial Good doesn't like it. Maybe EgoSoft doesn't like it.
Like it or not, the issue is still a problem to a lot of players -- and, frankly, most of them
don't care how hard it is to fix.
Most also won't bother making yet another forum account to air their grievance -- they'll just stop playing and casually bash the game to their friends in private when asked why they gave up on it.
In game development, "It's too hard" (usually pronounced
"It isn't feasible at this time") is a common delay tactic devs feed their PM to de-prioritize a nagging ticket.
But when Steam, or Apple, or whatever app store your game uses to generate the majority of its revenue says jump... well, impossibilities tend to become possible real quick when it affects the bottom line.
It could be naively argued that
this doesn't affect the bottom line because it only affects players after they've made a purchase -- but we all know that's not how it works.
Unhappy players -- especially when they feel they're getting ignored or blown off -- affect sales through the grapevine. That's just the way it is.
But, for the sake of argument, let us say that EgoSoft is perfectly happy with their current quarterlies. That still doesn't change the root of things...
If it's going to keep coming up, we should discuss it constructively.