Print

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

[profit]

Playability would increase if the rendering and the user interface were done by separate threads so that no matter how much simulation and pathfinding was being done, the rendering and user interface could remain responsive.

This would help single and multicored machines but the people with multicored processors would probably feel the most benefit, as the user interface would NEVER lag and the fps would NEVER fall.    The game itself would still be slow as the simulation ground to a halt on larger forts, but the game would accept keystrokes and commands in a crisp and snappy fashion.

This would eliminate the up/down Z level change jumping more than one level on keypress and laptops with their slower speeds having erratic input that makes it appear you hit the key 4 times.

This may also give the users of multicored processors a tiny amount of speed increase, but the real value would be on the presentation of the program.

[Draco18s]

DF already does this.  I've seen as many as seven OGL threads.

[profit]

I am betting the openGL API is doing it.  The actual render loop in the program which sends the data to the API does not appear to be.  If it was FPS would be simulation speed agnostic.

[Qloos]

What?

[CobaltKobold]

I am betting the openGL API is doing it.  The actual render loop in the program which sends the data to the API does not appear to be.  If it was FPS would be simulation speed agnostic.

Except the "FPS" counter in DF is simulation "frames" per second, not display frames. How many time quanta are simulated in a given real second, if you will.

(Psst. He means that display speed would be independent/not care how fast sim was running)

[profit]

I am betting the openGL API is doing it.  The actual render loop in the program which sends the data to the API does not appear to be.  If it was FPS would be simulation speed agnostic.

Except the "FPS" counter in DF is simulation "frames" per second, not display frames. How many time quanta are simulated in a given real second, if you will.

(Psst. He means that display speed would be independent/not care how fast sim was running)

You are right in that I am not exactly sure what the "frames per second" counter does count*, but it's immaterial as the user interface bogs down with the program and makes it act like you have tar under your keys as you press them.

* time to fire up fraps to get a real count.

[Mikademus]

Could we PLEASE see a stop to all the threads requesting multi-threading? Had you searched you would have seen this brought up quite a few times already... You want to discuss the topic more necro an existing thread! :sigh:

[Draco18s]

I am betting the openGL API is doing it.  The actual render loop in the program which sends the data to the API does not appear to be.  If it was FPS would be simulation speed agnostic.

Except the "FPS" counter in DF is simulation "frames" per second, not display frames. How many time quanta are simulated in a given real second, if you will.

(Psst. He means that display speed would be independent/not care how fast sim was running)

You are right in that I am not exactly sure what the "frames per second" counter does count*, but it's immaterial as the user interface bogs down with the program and makes it act like you have tar under your keys as you press them.

* time to fire up fraps to get a real count.

Or open up your init file and find your GFPS setting.

[profit]

Could we PLEASE see a stop to all the threads requesting multi-threading? Had you searched you would have seen this brought up quite a few times already... You want to discuss the topic more necro an existing thread! :sigh:

Those threads mostly deal with multicore support.  While multicore support requires multithreading, multithreading does not by itself make a program take advantage of multicored proccessors.   Breaking off a UI thread from the main loop is nothing like making Mutex's, stopping Loop-carried Dependence, and preventing Data-race Conditions for multi-cored support.  (While fairly easy to do, it requires a significant change in programming style)

And the reason I said that I was going to use FRAPS draco18s is because according to information you quoted in that message he said that the real frames per second is different that what is reported.

But I just checked and FRAPS reports frames per second matching Dwarf fortress so indeed the render loop is embedded inside the simulation loop and NOT a separate thread no matter if their are 7 openGL threads or not.