Print

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

[bliantfive]

Hi,

lets say i have a nerdy idea that needs DF to run at 1 or 2 FPS.
This is working fine on vanilla DF but its not working while using a graphics pack.
I managed to get it down to 10 but thats still to fast and i cant get it lower.
When i set the cap to anything below 10 it just caps at 10 instead. The ingame commands also stop at 10.

Is there any way to set the FPS to 1? And if so: Is there a way to keep the graphical FPS above this value?(right now its following the game fps down to 10 while beeing set to 25)

[Tecknitian]

You could try using cheat engine.

[Putnam]

You could try using cheat engine.

Or DFHack, which in behavior is almost exactly a high-level API for cheat engine that happens to include a "setfps" command.

[bliantfive]

Thanks guys!
The notion of DFHack actually helped a lot.

When installing DFHack and dissabling the option "tweak fps-min" it works. (I would say "like a charm", but the nature of 1fps is that its not running like that.  More like a dwarf who is supposed to pull a lever.)

Now theres just one problem left:
The UI fps are linked to the calculation fps. Meaning that the ui cant run faster than the calculation.
Is there a way around that?
I could live with it, but it would make my life so much easier if i could find a solution.

[Putnam]

The GFPS is at most the FPS. GFPS is what controls the UI. No way around it. This is why fps-min exists, heh.

[bliantfive]

The GFPS is at most the FPS. GFPS is what controls the UI. No way around it. This is why fps-min exists, heh.

To bad.
But in a 32 bit environment thats what i expected. Its terribly hard to unlink things like that in a matured project.
Im really excited for the 64bit version though. Now that this step is done (which i didnt expect) maybe we even see threading become a thing in DF somewhere in the future. Then it might be possible to separate the gfps from the calculation.

Thx anyway.
You'll hear from my crazy dwarfy project within the next few days i guess.

[Putnam]

32-bit is completely unrelated to this and 64-bit is completely unrelated to multithreading.

[Miuramir]

The GFPS is at most the FPS. GFPS is what controls the UI. No way around it. This is why fps-min exists, heh.

This may need to become a suggestion going forward.  I would be thinking in terms of hoping for something that broke out the following as separate variables to cap / optimize:
A) Number of simulation ticks calculated per second
B) Number of times the output routines update per second; logically limited to no more than A) but in some cases hardware or OS issues might force more frequent pseudo-updates even if nothing has really changed
C) Number of times the display routines animate per second; could be several times that of either A) or B) in cases where, for example, water animates colors.  In weird cases (remote play on low-end devices, perhaps?) it might be less than B)
D) Number of times the input routines check for things like keystrokes and mouse movement; logically limited to no more than C) in *most* cases, but in perverse cases (such as bot play) where A) or B) might be larger, would be limited by that instead. 

Unfortunately, as I understand it currently, D) is limited to B) is limited to A). 

You might need an additional parameter to handle current tech 3D / VR displays, which basically requires drawing things twice even if they're the same, to avoid perceptual "tearing" between eyes. 

[Putnam]

The game currently has 8-10 threads AFAIK, all of which excepting one are related to input, sound and display (I.E. SDL).