More height levels (in trunk since r27010)
Posted: 06 Dec 2008 18:11
===================================================================================
State of the patch: In trunk since r27010
===================================================================================
Hello,
similar to the not-finished patch in http://www.tt-forums.net/viewtopic.php?t=33231, I want to try to add support for much more than just 16 heightlevels.
The basic thing probably is the decision how to save new height levels in the Tile-datastructures. What I so far didn't understand is why the TileExtended-type exists. What didn't you put m7 into the Tile-type?
Today, tile_height consists of 4 bit saving the height level and 4 bit saving the class. I think, two ways of having more height level information are possible:
(1) introduce one extra byte per tile. Then, the height is saved in 12 bit and the class in 4 bit.
(2) introduce two extra bytes per tile. Save the height in 16 bit and the class in 4 bit, having four extra bits not used so far.
Having possible underwater heightlevels in mind (maybe one could introduce a "bridges can only be built in flat water"-patch in the future), I would make the heightlevel-information signed.
So, (1) would allow 2048 heightlevels, whereas (2) would allow more height levels a reasonable map can have.
And no, having just 128 heightlevels is a bit too less in my opinion. I want to be able to introduce really huge mountains, forcing the player to build railways only in the valleys because the peaks are too high. And given the amount of work such a patch involves, if I do this I want to implement a patch where one will never again feel the need to introduce more heightlevels.
For example, in a scenario of the Austrian mountains, one could play using a scale of "each height level represents 10 or 20 meters in reality, thus bridges having (nearly) realistic heights.
I think (1) is a good choice in terms of memory, but (2) would have the advantage of getting rid of the bit-shifting when distinguishing the height level from the class information.
Looking at http://www.tt-forums.net/viewtopic.php?t=33231, I suspect that there is one minor and one major place where I have to expect problems: The minor one will be the savegame loading and saving code. The major in my expectation will be adding support for the new heightlevels to the graphical algorithms, avoiding graphical glitches and inefficient algorithms.
What do you think about it?
State of the patch: In trunk since r27010
===================================================================================
Hello,
similar to the not-finished patch in http://www.tt-forums.net/viewtopic.php?t=33231, I want to try to add support for much more than just 16 heightlevels.
The basic thing probably is the decision how to save new height levels in the Tile-datastructures. What I so far didn't understand is why the TileExtended-type exists. What didn't you put m7 into the Tile-type?
Today, tile_height consists of 4 bit saving the height level and 4 bit saving the class. I think, two ways of having more height level information are possible:
(1) introduce one extra byte per tile. Then, the height is saved in 12 bit and the class in 4 bit.
(2) introduce two extra bytes per tile. Save the height in 16 bit and the class in 4 bit, having four extra bits not used so far.
Having possible underwater heightlevels in mind (maybe one could introduce a "bridges can only be built in flat water"-patch in the future), I would make the heightlevel-information signed.
So, (1) would allow 2048 heightlevels, whereas (2) would allow more height levels a reasonable map can have.
And no, having just 128 heightlevels is a bit too less in my opinion. I want to be able to introduce really huge mountains, forcing the player to build railways only in the valleys because the peaks are too high. And given the amount of work such a patch involves, if I do this I want to implement a patch where one will never again feel the need to introduce more heightlevels.
For example, in a scenario of the Austrian mountains, one could play using a scale of "each height level represents 10 or 20 meters in reality, thus bridges having (nearly) realistic heights.
I think (1) is a good choice in terms of memory, but (2) would have the advantage of getting rid of the bit-shifting when distinguishing the height level from the class information.
Looking at http://www.tt-forums.net/viewtopic.php?t=33231, I suspect that there is one minor and one major place where I have to expect problems: The minor one will be the savegame loading and saving code. The major in my expectation will be adding support for the new heightlevels to the graphical algorithms, avoiding graphical glitches and inefficient algorithms.
What do you think about it?