I have implemented the simple changes, some more complex changes remain to be done. Nevertheless, here an intermediate release.
In detail:
Comment fixes and code improvements in patches 10 and 20 are fixed.
+#### I like 999 much better. Especially because this way is going to break horribly when adding sprites to openttd.grf, because it reduces the number of GRFs that can be loaded by one, and finally because it's a blob without source and a few Linux distro's want to build everything from source. If not, then it's deemed 'non-free'.
I perfectly agree, the only reason why I didn´t yet switch to 999 is that at least some weeks ago, 999 needed a recompile of a patched nforenum. As soon as the infrastructure is in a state that allows a 999 patch being applied and successfully compiled without problems, I happily switch to 999.
I'm missing a complete picture here. Columns, rows, regions and some other words are used, but I'm not really getting what they mean exactly when reading this. What is the basic meaning of those words, and what is the basic idea of the drawing algorithm?
I try to explain a bit more about this here:
The drawing algorithm receives a rectangular section of screen, and needs to redraw that section. The problem now is, how to determine what tiles are affected by this. To the left and to the right, things are quite simple, the x screen coordinate where a tile is painted does not depend on things like heightlevel, objects on the tile, etc.
More complicated is the vertical direction. The higher a tile is, the more it is painted in the north. The higher a building or bridge on a tile is, the more it is painted into the north either. Thus, if a tile has a relatively big heightlevel, it may need to be painted, although a tile with the same TileIndex, but heightlevel zero would be far south of the visible area. In other words, the decision if some particular tile intersects the painting area in vertical direction highly depends on the tile state.
What one knows for sure (in the absence of bridges, as the recent discussion showed) is that a Tile with smaller TileX/Y is painted north of a Tile with bigger TileX/Y, just the difference can vary. Thus, given some screen coordinate that is the boundary of the top be painted area, one can use binary search for finding out which tile is painted at, or at least near that screen coordinate.
Thus, if you do that binary search both with the upper and with the lower boundary of the screen, you get the area of tiles to be painted.
Now, the meaning of the words above: As I have said, to the left and to the right things are simple. Thus, I divide the set of tiles into columns. Tiles that are exactly north or south of each other are in the same column. A unique column index can be calculated quite simple based on the tile coordinates.
For each column, I determine the topmost and bottommost to be painted tile, as described above. Here, rows come into play: All tiles that area exactly west or east of each other are in the same row. Thus, the result of that calculation is not just a tile (that is at that stage not that interesting anyway), but a row.
Once this is done for all columns, I for each column have a top and a bottommost row to paint. The minimum top row and the maximum bottom row finally constitute the borders of the to be repainted area.
Does this explain your questions? If no, please ask again.
+#### Can't maximum_height_level be used as well? On 4kx4k map at tile 0,0 I doubt you need to search till 4k,4k. If maximum_height_level = 32, then I'd expect it to be at most a 32x32. This should shave off a couple of iterations on average.
Probably you are right, I thought about something similar in the last few days already. I will have detailed look on that.
Patch 060 should be clear now, no changes needed.
Patch 090 and 100: The minor code changes are fixed, however:
+### Can't this logic be shared with aircraft? It looks duplicated.
It indeed looks duplicated, unfortunately aircrafts and disaster vehicles don´t have a common superclass where the variables this code relies on could be defined. Thus IMHO, the answer is No, there is nothing to unify sensefully.
Patch 140: Comment and code issues fixed.
Patch 150, smallmap: I will have a look on it. Probably, I somehow need to scale the access to those color tables.
Patch 155, 157: Cheat vs. setting: I have just searched
+#### Why a cheat and not a setting?
I have just dived into three-years-old forum posts. See e.g.
http://www.tt-forums.net/viewtopic.php? ... 60#p980387
http://www.tt-forums.net/viewtopic.php? ... 80#p980488
and my answer
http://www.tt-forums.net/viewtopic.php? ... 80#p980514
I have just tested it: As far as I get it, I indeed cannot change the existing setting set on map generation in scenario editor. I.e. when I generate a landscape in scenario editor, and then realize, I want a higher mountain than allowed, I have a problem with the current setup, unless I use the cheat.
I think in-game changing that setting is indeed not that important, but in scenario editor the ability might sometimes be useful IMHO.
+#### Don't you know the 'column' and as such the tile height there? Can't that be used to calculate the max scroll outside of map? I fear that this way gets people into a black screen; it even took me a while to scroll out of this blackness when being zoomed in fully. As such, I think this will cause some bug reports of new users that are lost in a black screen.
I see the problem. Probably, I can do something by indeed inspecting all visible columns. I can restrict that calculation to the case that one is beyound the usual map border at height zero. Just code will become a bit more complicate than when I compare just with a constant value.
Landscape generation: I will have a look.
