Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kaijyuu]

(posted here and not suggestions because I'd like to hear more opinions on this, not just submit an idea to Toady)

FPS death is probably the most common killer of forts. More than gobbies, more than magma, more than elephants, giant sponges, or hordes of giant mosquitoes. Without rather extreme care and limiting oneself from some of the more fun aspects of DF, CPU use will creep up and up until it surpasses the player's tolerance for sitting around waiting for things to finish happening.

People are always asking for pathfinding or item calculations or units to be sped up so this doesn't happen. There's another alternative, however: just making things happen over less frames.


The init file states that an average dwarf will move 1 tile every 10 frames. What if this (and every other action) were halved? The game's speed, as far as the player is concerned, would be twice as fast, despite the framerate being exactly the same.


Now I realize things are a bit more complicated than that. For one, obviously we lose some precision, perhaps most important for adventurer mode. Movement could be troublesome for anything moving really fast like bolts and bugged supersonic wagons, as they (might) be moving 1 tile per frame already. If Toady happens to be a fan of magic numbers, it'll also be hellish to look over the code halving everything. Another thing to remember is chokepoints that aren't encountered every frame (cough pathfinding cough) will not be improved by this.

Still, CPUs are moving toward more cores, not faster individual cores, meaning single threaded applications like DF can't wait for technology to catch up. A computer 5 years from now will probably be able to play DF better than ones today, but not by huge margins (barring some breakthrough). Optimization's one choice, but another is just making the game go faster.

[Nihilist]

I'd think making the game do the same amount of calculations in LESS time will actually have the opposite effect, and actually slow down simulation.

[kaijyuu]

You've got it backwards. It would be less calculations in the same time, not less time for the same calculations.

The downside is loss of precision. If action A happens on frame 8 and action B happens on frame 9, and the game's speed were doubled, both actions would instead happen on frame 4, potentially causing different results since they happen simultaneously rather than one after the other. This could affect things like combat. Not a huge deal though IMO, unless it goes too far.

[Buttery_Mess]

DF needs the dwarfs to move about one tile every ten ticks to properly manage the different speeds of different creatures. It's a matter of keeping the program handling integers, not floating points.

[kaijyuu]

Ah, yes if movement were done entirely with whole numbers that would definitely be a problem. Though TBH even with 10 ticks per average movement, that's a precision problem right there; you'd need a full 11% boost to whatever the speed stat is (agility?) to bump that down to one tile every 9 ticks. The intermediate stat points would be useless (for movement, anyway). 

But if that's how the game's coded, then /shrug

[Buttery_Mess]

I'm not 100% certain that the movement calculations depend on integers, and I'm not a programmer. I see little signs about though that integers are preferred over floating points, because I know enough about programming to look for that.

It's unfortunate that everything needs to path everywhere and recheck its path all the time, and that you have to build forts over multiple z-levels, because this is the unavoidable factor causing slowdown. If you sped everything up 10x, you'd have the pathing checks  occuring only 10% as often. I haven't looked into it in depth, but I'm pretty sure my dwarves aren't pathing every tick or even every ten ticks. I'm pretty sure I've seen enough woodcutters stroll cheerfully outside of a burrow and walk ten paces into a cluster of goblins before realising where they were and what they where doing. I can only surmise that they don't path often enough when they aren't being blocked or drowned or burnt by magma or shot at by goblins.

[robertheinrich]

This suggestion is dumb not really thought through. What kills the FPS after a while is that the explored world gets bigger (more pathing), the number of units like dwarves, animals, invaders, cave dwellers etc gets bigger and bigger (more pathing/decisions). Added to that are game physics if you start using pump stacks and whatnot. In short, the number of calculations the game needs to do per time frame increases and without a faster processor there´s not much you can do (except multithreading while having lots of cores, but than can be a bitch to implement, so I can understand that Toady is a bit reluctant about it).

Now if you would speed up all the units they would arrive at their destination sooner and have to recalculate their next actions and pathing more often - leading to more calculations required at the same time, where you hit the boundaries of your cpu again. Also... as you say a dwarf moves 1 tile every 10 frames and think that it would be better to cut down that value. But you ignore that faster movement for other stuff (predator animals, FBs, xbow bolts, ...) is crucial for the gameplay.

Go check how fastdwarf behaves on a big map with lots of enemies and/or lots of pathing (tell 200+ dwarves to dump a big area full of stones or whatever). Better yet, go code a simluation of your own. It may help you realize that your assumptions are misguided.

[Rafal99]

If I understood correctly what you ask is basically increasing dwarf speed x2. You can do it in the raws right now. You would need to change other creatures speed too if you want combat to remain fair.
But it won't magically make the game 2x faster. The game would need to make exactly the same number of pathing requests anyway.

As for integers, as far as I know Toady uses only them. Memory hacking guys would probably know for sure.
But using integers only doesn't mean using whole numbers only. Actually default dwarf speed is like 1000, so 1% faster is 1010, no fractions are even needed. Such dwarf would probably need 9,9 ticks per move, which can be realized by moving him each 10 ticks in 9 moves, then after 9 ticks in 10th move, then repeat.

[kaijyuu]

@robert

Your assumption is that pathing is the largest cause of framerate issues. This is not the case for my forts, where items and number of alive units existing is.

I can seal everything up in a 1x1 tile with food/booze and zero jobs, and my framerate does not significantly increase. Only when they die does it go back up.

Dumping every item on the map in magma flows doubles my framerate as well. More so if I have temperature on.


Liquid movement is another thing that speeding up the game would not be improved by, that's true. It's also something that doesn't kill my framerate (unless I go crazy with a dozen waterfalls).


Now all of that is "my framerate." It's fort dependent and computer dependent. You stick a bunch of waterfalls on your map, and yeah liquid movement is going to be a significant drain that speeding up the game would not help. Also, pathing and liquid movement get exponentially worse the worse your computer is; a modern computer can handle quite a bit of it in this, game, actually. But get one that was only decent 5 years ago, and both are significant drains even in small amounts.


Finally, do be careful about throwing out things like "need to think it through more" or "do it yourself." My lack of confidence in this suggestion is the very reason why this topic is in this forum and not suggestions. The latter is rude and a stupid response to pretty much anything. Toady could kick my ass writing any pathing engine, it's true, but I'm not ignorant of how game engines that deal with massive numbers of objects and units work. If my "qualifications" to make suggestions like this are somehow inadequate, it's due to ignorance of Toady's program specifically, not ignorance of programming.


@Rafal
Editing the raws won't speed up the calendar. Dunno about things like workshop jobs, too

But it won't magically make the game 2x faster. The game would need to make exactly the same number of pathing requests anyway.

Yep. That's why I said exactly as much in the OP.


As for the rest, technically nothing uses fractions or percentages; just representations of them. A float is just a bigger int, with a decimal point stuck in the middle. It's faster to use ints over floats if you're doing a ton of calculations with them. But in this game, if we're recalculating stats (to take into account status effects, weight, etc) every single frame... well there's your humungous drain on CPU time with more units. However, I doubt that's the case given the vampire and were creature speed bug. Things have a lot of attributes in this game, but so long as they're only recalculated when needed, it's not remotely a significant CPU drain, and wouldn't be more so using floats or doubles instead of ints. If this is an issue, it's an issue with having to recode much of the game to get a tiny bit more precision, not to gain any sort of framerate boost.



----



Really people need to stop beating the pathing drum. Unless Toady's doing something monumentally stupid with it (which I very much doubt) a thousand or so pathing units is not going to kill any decent computer's framerate. Pathing happens relatively rarely; 1 path to find its way to its destination, and only more if something gets in the way. The bigger the map, the more it matters, but unless you're mining out entire z levels on a 4x4+ embark and/or have over 400 dwarves... (and even then I'd blame it more on increased temperature calculations/etc)

And to preemptively counter everything I know is coming: A reduced framerate due to pathing would be quite jerky. If your dwarves seem to shoot forward 2-3 tiles, then stop on 1 for a third a second, then continue, then pathing's your issue. Any steady, non-incredibly fluxuating framerate is not being significantly slowed by pathing. Also, in my experience, framerate fluxuates quite a bit normally; I go between 80-140 on my forts all the time (one fort wildly swung between 100 and 280 for months at a time). I'm hesitant to believe anyone who says sealing things off or traffic designations gave them a "10-20 fps boost," since a 10-20 fps boost can happen normally without any action from the player. (Not to say it's not possible or that those things don't help, just more likely to be regular FPS fluxuation from random crap like wildlife leaving the map/etc)

[Meph]

I went another way. I standardized most (90%) of the materials.

If the game has 200 different creatures, and each has 10 bodyparts, and you can make leather/thread out of them, and you can make 20 different items with this, you have thousands upon thousands of different item types to keep track of.

I only have 1 of each. Leather is Leather, every Leather item is just that, "leather" item. No custom names in front. All trees give "wood" and so forth. Same goes for blood, silk, meat, milk, bones, you name it... I left some things in for flavor, but I had reports from players that had about 25% increase in framerate (even with temperature on) and one posted that his 150 dwarf-fortress was still running at 150 FPS.

[zombie urist]

I believe that there was a thread about scaling the speed of all creatures before with results similar to what you described, such as xbows becoming chainguns...

[Yaotzin]

The init file states that an average dwarf will move 1 tile every 10 frames. What if this (and every other action) were halved? The game's speed, as far as the player is concerned, would be twice as fast, despite the framerate being exactly the same.

If you doubled the frequency of every action, you would halve your FPS, whilst doing more "stuff' per frame. The end result being identical. Of course, you could not double the frequency of things already running every frame.

I assume you're talking about increasing the frequency of only certain things, like movement and construction speed? I would strongly oppose such a move as I find the game far too fast with legendary dwarves anyway. It's impossible to keep up with them.

[Nihilist]

You've got it backwards. It would be less calculations in the same time, not less time for the same calculations.

The downside is loss of precision. If action A happens on frame 8 and action B happens on frame 9, and the game's speed were doubled, both actions would instead happen on frame 4, potentially causing different results since they happen simultaneously rather than one after the other. This could affect things like combat. Not a huge deal though IMO, unless it goes too far.

Your suggestion is essentially to have things that would occur 1 time per every 10 frames to occur 1 time ever 5 frames.

The init file states that an average dwarf will move 1 tile every 10 frames. What if this (and every other action) were halved? The game's speed, as far as the player is concerned, would be twice as fast, despite the framerate being exactly the same.

This means in 60 frames instead of 6 tasks occurring, 12 tasks occur. Not only do you lose precision but you are now asking the simulation to do double the calculations in the same time frame.
Since you have doubled the amount of tasks per frame, in a perfect world you would halve your FPS, meaning no discernible difference. Since this is not a perfect world, and because you are increased the complexity of each frame it will likely decrease by more than half giving an overall slow down in simulation speed.

[KFK]

I went another way. I standardized most (90%) of the materials.

If the game has 200 different creatures, and each has 10 bodyparts, and you can make leather/thread out of them, and you can make 20 different items with this, you have thousands upon thousands of different item types to keep track of.

I only have 1 of each. Leather is Leather, every Leather item is just that, "leather" item. No custom names in front. All trees give "wood" and so forth. Same goes for blood, silk, meat, milk, bones, you name it... I left some things in for flavor, but I had reports from players that had about 25% increase in framerate (even with temperature on) and one posted that his 150 dwarf-fortress was still running at 150 FPS.

I'm curious about this for aesthetic reasons. I'd much rather have 50 'Wooden Doors' than 50 different entries for oak, ceder, pine, whatever... even if there were no performance gain.

Details?

[Meph]

I dont want to hijack the thread, so please leave me a PM with what you want to know. All in all it is quite complicated. I mostly did it to make the list of building materials shorter. This way people have to scroll less, need less time for contructions and the like, and can play more. The FPS was a bonus.