News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

bits_per_month and simunits

Started by Mariculous, February 12, 2020, 10:26:48 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

Not quite sure where to place general questions about the code, I guess it fits best here.

1. Is there any good reason why month lengths in ticks are defined as 2^bits_per_month, instead of setting the month length in ticks directly or is this simply a historical thing?
2. Why don't we have access to world or settings from simunits?

prissi

1) Several calculations involving month length exist. Those use shifts instead of divisions, which is easier to handle also precision losses due to bits falling off left or right. However, in principle, the performance penalty is probably neglibile nowadays if one changes to normal numbers. I would just affect a lot of places in the code.

2) Not sure what you mean here. Ticks per month cannot be sensibly changed during a game without breaking costs and statistics. The same it true for a lot of other settings, which is why the setting dialog is hidden in most pak sets.

Matthew

Quote from: Freahk on February 12, 2020, 10:26:48 AM
2. Why don't we have access to world or settings from simunits?
Quote from: prissi on February 13, 2020, 02:00:25 AM
2) Not sure what you mean here. Ticks per month cannot be sensibly changed during a game without breaking costs and statistics. The same it true for a lot of other settings, which is why the setting dialog is hidden in most pak sets.

Maybe he is asking why simunits.h, and in Extended, simunits.cc, do not #include simworld.h?? I am not a coder, so I am just guessing.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Mariculous

Thanks Prissi, so consistently changing this might be an option to relate ingame time to real world time more preciesely.
There is a lot of shifting stuff in the code anyway, where modern compilers would simply optimise to shifts anyway. I guess that's simply for hostorical reasons, I won't change that.

2. Mathew is right.
At least in extended code there are some extern declarations and setting values passed in the conversion function, where that could simply be read from settings directly if we had access to the settings.
So I was wondering if there is a good reason why one might not want to access settings from simunits.cc and the inlined functions in simunits.h

Btw. maybe that's an extended thing but I am 100% sure I had increased bits_per_month in my last game by 2 somwhere in the 1990s so It takes longer to get to the future.