Month lengths

The scheduler's highest level of granularity is 1/1440.

6.4 hours * 60 minutes * 60 seconds = 23,040 seconds/month.

23,040 / 1440 = 16 seconds/scheduling check.

12:42] Matthew | BR Cambrian & Central: In the course of writing these changes, did you get your head around the spacing_shift mechanism, or have you just left that part of the code untouched? I ask because I have been trying to understand why we have 6.4 hours per month. (I know that it's a function of bits per month and metres per tile, but not why a non-integer number is optimal.). I've worked out that it results in a minimum scheduling interval of 16 seconds, and I suspect that it's not coincidental that 16 is a power of 2, but not got further yet.(edited) @Matthew | BR Cambrian & Central In the course of writing these changes, did you get your head around the spacing_shift mechanism, or have you just left that part of the code untouched? I ask because I have been trying to understand why we have 6.4 hours per month. (I know that it's a function of bits per month and metres per tile, but not why a non-integer number is optimal.). I've worked out that it results in a minimum scheduling interval of 16 seconds, and I suspect that it's not coincidental that 16 is a power of 2, but not got further yet.(edited) [12:45] Freddy: I don't understand it either. I suspect it was a result of somebody trying to be needlessly clever. In reality, these things rarely have any meaningful effect on performance and it probably would have been better to use a more conventional time system.

1 [12:48] Freddy: It makes use of bit-shifting trickery (the << and >> symbols) that generally operate in powers of 2. They might have offered some marginal performance benefit in the 1990s but not really today.

1 [13:29] Freahk: Depends... bit shifting is still a legitime optimisation where very fast code is required, especially in case of right shift aka divisions by powers of two. But in many cases modern compilers will do those optimisations automatically anyways. [13:30] Freddy: I can't imagine it being very useful in simutrans though? especially for the cost of inhuman time formats... NEW [13:34] Freahk: About bits_per_month, that is the number of bits being used to represent a month, or in different words: an ingame month is 2^bits_per_month ticks long, where a tick is one millisecond in normal game speed. That's the relation to real-world time. The relation to ingame time comes from those ticks, meters_per_tile as well as a weird constant factor.(edited) [13:38] Freahk: I don' think it's a performance issue to use something like ticks_per_month instead of bits_per_month. I did some extensive experimentals about real-world and ingame time scaling to get rounder values, measured in real-world time as well as ingame time, whilst maintaining time, speed and distance consistency. [13:42] Freahk: My personal conclusion was that switching from bits_per_month to ticks_per_month is the easiest way to go, but will only result in either round ingame month lengths or round real-world time per month.

Given the much higher effort needed to tweak all the conversations, thus also scaling simmulation speed with the relation in between real-world time and ingame time, I guess "simply" switching from bits_per_month to ticks_per_month should be prefered.