- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "v0.34 Talk:Pressure plate"
(Created page with "The level of detail in this article is truly impressive. I thank thee, whoever had to do the experiments to figure it out. ~~~~") |
(→Expected FPS crunch from lightspeed repeaters: new section) |
||
| Line 1: | Line 1: | ||
The level of detail in this article is truly impressive. I thank thee, whoever had to do the experiments to figure it out. [[User:ZortLF2|ZortLF2]] ([[User talk:ZortLF2|talk]]) 18:44, 18 August 2013 (UTC) | The level of detail in this article is truly impressive. I thank thee, whoever had to do the experiments to figure it out. [[User:ZortLF2|ZortLF2]] ([[User talk:ZortLF2|talk]]) 18:44, 18 August 2013 (UTC) | ||
| + | |||
| + | == Expected FPS crunch from lightspeed repeaters == | ||
| + | |||
| + | I've played around with devices that send multiple open/close signals in close succession, e.g. ten doors linked to pressure plates, each activated two steps apart. The opening/closing sequence caused a massive slowdown of the game. A "flickering" door, run by a multi-plate repeater with a period of about 15 steps per full open&close cycle similarly caused massive lasting slowdown as long as it was active. | ||
| + | |||
| + | To verify, i built a simple door into a niche and ran it manually by a dwarf per Pull Lever/R - that reduced FPS from the low 40s to 12. It didn't matter if the door was accessible or not: i walled the door off, and even when completely surrounded by walls, putting the door on this fast repeat killed the frame rate; it _seems_ that pathing calculations aren't the main culprit. I don't know what exactly consumes all those cycles, but buildings that are opened/closed via mechanism definitely eat a lot of processing power, and it gets quite bad when this happens in quick succession. A true light speed repeater would probably not be very fun to run. --[[User:Larix|Larix]] ([[User talk:Larix|talk]]) 05:29, 17 March 2014 (UTC) | ||
Revision as of 05:29, 17 March 2014
The level of detail in this article is truly impressive. I thank thee, whoever had to do the experiments to figure it out. ZortLF2 (talk) 18:44, 18 August 2013 (UTC)
Expected FPS crunch from lightspeed repeaters
I've played around with devices that send multiple open/close signals in close succession, e.g. ten doors linked to pressure plates, each activated two steps apart. The opening/closing sequence caused a massive slowdown of the game. A "flickering" door, run by a multi-plate repeater with a period of about 15 steps per full open&close cycle similarly caused massive lasting slowdown as long as it was active.
To verify, i built a simple door into a niche and ran it manually by a dwarf per Pull Lever/R - that reduced FPS from the low 40s to 12. It didn't matter if the door was accessible or not: i walled the door off, and even when completely surrounded by walls, putting the door on this fast repeat killed the frame rate; it _seems_ that pathing calculations aren't the main culprit. I don't know what exactly consumes all those cycles, but buildings that are opened/closed via mechanism definitely eat a lot of processing power, and it gets quite bad when this happens in quick succession. A true light speed repeater would probably not be very fun to run. --Larix (talk) 05:29, 17 March 2014 (UTC)