On stephenson-siemens, everything was all right due to the small map.
On bridgewater, however, the maximum zoom is still quite tiny and the minimum zoom will still show very much black around a tiny map.
I would rather expect a constant size of minimap pixels in specific zoom levels, either constant in on-screen pixles or constant in on-screen percents.
This is not a bug - this is how the minimap has always been. That it might benefit from some improvement is not the same as it being an actual bug.
Could this be related with the minimap crash? https://forum.simutrans.com/index.php/topic,19882.0.html
Open small game, open minimap, zoom in, open big game, open minimap, crash because you tried to zoom in to unsupported level
Yes, it seems to be related.
I took a little look at this limitation, but I don't know much about it, so I need someone's perspective.
I found a comment in the code as to why zoom in is limited on large maps.
https://github.com/jamespetts/simutrans-extended/blob/f2aab7f6dca1201a3751eb23650f092b061ea6f1/gui/karte.cc#L534
Is it difficult to mitigate zoom-in? (´・ω・｀)
I had a look a the code and it's actually correct that your linked line forbids the game to zoom in further, to prevent an overflow in karte_to_screen.
karte_to_screen is quite straight forward: It takes a map koord and multiplies it by zoom_in and divides it by zoom_out. One of these two is always 1.
That will result in an overflow for sure, if koord * zoom_in is greater or equal to 2^15.
Later, that calculated screen koord will be offset according to maps viewport.
I see two possible solutions here:
1. Use an sint32 version of the screen koord.
2. Apply the offset before scaling to screen koord.
Applying an offset to coordinates before passing them karte_to_screen, so the top-left corner of current minimaps viewport is (0,0) will circumvent the overflow entirely.
That, however, requires reorganising the minimap drawing code.