Engines allow you to do whichever one you want – some things, you may want to tie to framerate, so the option is of course there. But it's not difficult to measure the time that passed between the two update calls (the delta time) and use that for further computation. For example, let's say you want to animate a progress bar filling up. The naive approach is to fill it by a little bit with each frame update, which will lead to the issue you mentioned. In any serious environment, however, such a solution will be returned to you with a request to redo it. So what do you do? You decide that the bar should fill in 10 seconds, for example, so you know that after 1.5 seconds, it should be 15% full. Then it's just a matter of storing the time when the whole operation began, and each update asking "How much time has passed since the start of the operation? 2.16 seconds? Then set the bar to be filled at 21.6%." This way, the bar will be filled after exactly ten seconds regardless of the actual FPS. This general approach can be used for anything, in order to decouple actual game logic from framerate.
Indie devs tend to be worse at optimization than bigger studios, for three reasons: Experience, Money, and Manpower. In a big studio, it's normal for team leader to go "Hey Joe, we have some performance issues, so spend the next week profiling memory and CPU usage." But a smaller studio can often not afford to spend such a period of time without one of the developers. Also, I find, the smaller studios tend to have inexperienced devs that never worked in a really big team (and thus are mostly self-taught, rather than being coached by seniors you find in bigger studios), and you sort of need to know what you're doing and what to look for when optimizing things.
Imagine actually letting this bother you during the so-called "training." Ignore it.
tranny dwarfs
CPU is always a problem. Large companies release specific products for cryptocurrencies but not for DF
It isn't processing power that's the issue with DF, but optimisation and design.
The game still has no significant multi-threading support, and Toady says he finds it too confusing to implement. Multi-threading would help a lot with DF as the game has a lot of things going on that could be offloaded.
It also doesn't help that Toady isn't a trained programmer and generally seems to work to a "if it compiles, it's good enough" style of development.
