Is there any way to fast forward time in the game like how zomboid can “fast forward” reading a book or how some people turn on speed hacks for walking simulator games like onward?
I can understand not wanting to cheese the game by taking a few in games to craft some higher level gear, but some actions take way too long to wait through. I’ve had time to take a leak, get a snack, and come back to find some tasks only 50% done. And I don’t have enough processing power on my computer to run a second game at the same time while i wait for it to finish…
Based on what I understand and through personal experience, the speed of the game is heavily reliant on the CPU of whatever you’re running the game on. For example, the old laptop I have used to play C:DDA before takes insubordinate amounts of time to sleep for a few hours (upwards of 2 minutes or so), whereas on my PC it takes 10 to 15 seconds due to a powerful CPU. I would assume that RAM has some part to play in it as well, but it seems to be less important.
As for what you can do to speed things up, I’m not sure. I think you can set a multiplier for construction times for a world, but to my knowledge you can’t do that for anything else.
unfortunately it seems geoforce now doesn’t have ways to run unsupported games then it seems…
Do you mean GeForce? I have a GeForce card and C:DDA runs just fine.
No, as ERROR_CODE stated, the game runs basically on the max of the computers CPU power.
That’s actually the culprit, not just a symptom. Faster processing power would mean faster sleeping/reading/waiting and other turn consuming actions.
I’ve noticed you can reduce the (real-) time it takes to do things in game by turning off the Experimental 3D field of vision in the options, having no monsters (or NPCs) in the reality bubble, having only as few items as necessary on yourself and in the reality bubble, and to save often (although this sometimes leads to long loading times once you step into map parts with a lot of items/monsters).
I’ve actually once tried to speed up the game using the Cheat Engine’s function of providing a faster clock speed than the system clock. It did nothing, which pretty much confirms that it’s already running at the max system speed.
Should probably mention that you could try overclocking your CPU to increase the game speed (as well as plenty of other things). Just be warned of heating and power supply issues. If you aren’t able to start your PC after overclocking, either short the CMOS or remove the motherboard battery for 10 seconds to reset the BIOS. If you’re on a laptop, I wouldn’t recommend overclocking.
So… The game is not multi-threaded?
There is still no point in upgrading to 24-core AMD?
Would be awfully nice to have 1 core per Z level or alike.
I don’t know your current CPU, but it is very possible a CPU with more threads will be more modern and more performant on single threaded tasks.
That aside, multithreading is not magic, it doesn’t necessarily make things faster (or even the same speed as non-multithreaded), on top of making everything harder.
several key developers (including Kevin) already have horror stories about debugging threadlock races that have a 3+ hour run time to reproduce for their day jobs and are extremely insistent that they do not want to take on that kind of debugging for their free time hobby. So adding multithreading is a non-starter, because it will substantially shrink the pool of talented developers who will contribute code changes.
multithreading massively increases the overhead of maintaining the game. that’s an ongoing overhead that just never goes away, it worms its way into every part of the system. for example, if anything but thread #1 wants to touch a data structure, that data structure must now be threading-safe and/or protected by locks
also, we use mingw for windows builds, it turns out mingw does not have working POSIX locking primitives. (if you do multithreaded on mingw, you abandon linux portability and use windows locking primitives). This is another huge maintenance burden.
problem #3 is that multithreading doesn’t get you performance improvements as fast as almost anyone thinks it will. to break that down, threading is relatively good for throughput, but it’s hard to use it to improve latency. as it turns out, user-facing programs almost never care about throughput, they only care about latency, so that kind of sucks. so for example, one of the expensive things we do is calculating FoV, it turns out it’s what’s called embarrassingly paralleizable, if a little tricky. i.e. you can break it up into 8 almost entirely independent jobs. The catch is, that task is actually dominated by cache misses instead of computation, and multithreading makes that worse, because you have to ship the input and output data aound to the various CPUs. so splitting that task up is relatively easy, but I’m not at all certain that doing so would make it any faster.
we had some mystery regressions and some not-so-mystery regressions since 0.E, subsequent improvements have clawed all that performance back and more. so we’re in pretty good shape now
which brings me to the “soft” problems with multithreading. say we do get good multithreaded optimizations and performance increases linearly with cores (so much lolnope, performance almost always increases with diminishing returns). I develop on two systems, one has 8 functional cores and the other has 12 functional cores. In the perfect multithreading case, there’s a 50% performance difference between the two systems, so a code change with performance that is barely tolerable on the 12 core system is untenable on the 8 core system.
keeping dda single threaded helps keep me (and the other developers) honest, because it narrows the gap between the best and worst systems available. it also narrows the gap within the userbase, including extreme cases where people are still on single or dual core CPUs
finally there’s the opportunity cost issue. for the effort of multithreading key parts of the game, we can put a hell of a lot of investment into more generally applicable optimization. there’s a hell of a lot of cache coherency and algorithmic optimization we have planned that we haven’t gotten around to yet. Optimizing the code would result in some sophisticated and finely tuned code we have to maintain, but we don’t have to worry about the rest of the code being hard to maintain
that’s the worst thing about multithreading IMO, as soon as you have multiple threads, you have to start worrying about thread safety throughout your code
1 Like
As someone who has written some multithreaded programs in the past, I strongly agree.
In my project collection I still have a multithreaded “basic bot” (a mix between a macro and logic) that I use to test stuff in CDDA which shows weird behaviors because of that, and I can’t wrap my head around as for why exactly or how to fix it…
One other thing to keep in mind concerning the performance problems… It might be related to the renderer, as KliPeH and anothersimulacrum pointed out in another post and topic:
…Some renderer were at least 3 or 4 times faster than others (this also includes long tasks like reading and crafting) when I’ve tested it, so it might be worth to give that a try.
1 Like
Can confirm, switched my renderer recently for approximately 3x performance improvement. It makes a surprisingly large difference.
Default Direct3D11 became awful on my GTX970 - 1 move feels like 3seconds in real life, while OpenGLes2 is fairly instant.
I’ve had to switch renderer a month or so back after one of the updates (experimental), but before that it was still running default (Direct3D ?)
This is unlikely, but still: make sure you are running x64 version if your system supports that. That one is noticeably faster.