More height levels (in trunk since r27010)

[ic111]

===================================================================================
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?

[planetmaker]

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?

I was told that it is mainly an alignment thingy in memory (better performance, if blocks of 8 bytes are allocated than blocks of 9). For the sake of the data structures it could have been in tiletype.

(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.

It would increase the savegame size by approx 10% and 20% respectively (ignoring vehicles, orders + settings).

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.

That's not necessary. You just need to define a global sealevel - and mark anything below that as water. It saves you the hassle of this bit

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.

Taking a whole byte would make things lighter on memory and 256 height levels should be sufficient.

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.

It should not be a big problem to make a conversion algorithm from the old map format to the new.

The major in my expectation will be adding support for the new heightlevels to the graphical algorithms, avoiding graphical glitches and inefficient algorithms.

That certainly is the biggest thing. Not sure though; I guess the biggest problems might be "underwater" and steep slopes, e.g height differences larger than one between tiles.

[ic111]

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?

I was told that it is mainly an alignment thingy in memory (better performance, if blocks of 8 bytes are allocated than blocks of 9). For the sake of the data structures it could have been in tiletype.

Ah. So staying at solution (1), this would mean that m6 goes to TileExtended and tile_height becomes uint16.

Can anybody tell some background information about the "blocks of 8 bytes"-argument? How important is this compared with the design disadvantage of having the members for one Tile in two different datastructures?

(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.

It would increase the savegame size by approx 10% and 20% respectively (ignoring vehicles, orders + settings).

Yes, I know. And I would prefer (1).

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.

That's not necessary. You just need to define a global sealevel - and mark anything below that as water. It saves you the hassle of this bit

Yes, this is probably the better solution.

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.

Taking a whole byte would make things lighter on memory and 256 height levels should be sufficient.

You are right, 256 is a rather big number, but one doesn't know how people want to play in future. And in fact, I think that scaling OpenTTD wouldn't be a bad idea. Imagine some 2048 x 2048 map. It contains much more cities than one human player can serve in a reasonable time. But, if an aerage city wouldn't have size 10 to 20, but size 50, things would look different. Then, stations would have a reasonable size compared to a city (e.g. 6 track station compared to size 50 city), and so on. And this may involve having much more heightlevels as well.

And anyway, the bit magic is concentrated in just one place in tile_map.h, so I don't see the difficulty in building a uint16 from one byte plus 4 bit.

The major in my expectation will be adding support for the new heightlevels to the graphical algorithms, avoiding graphical glitches and inefficient algorithms.

That certainly is the biggest thing. Not sure though; I guess the biggest problems might be "underwater" and steep slopes, e.g height differences larger than one between tiles.

[/quote]

No, I don't want to introduce such things. I just want to increase the max. allowed height from 15 to a much bigger number.

[Moriarty]

Non-technical point - but what would more height levels gain us? Specifically, how would the game be changed with just bigger hills?
Personally I don't see what would be gained from something like this without changing the game so that it could handle different elevation increases between tiles (i.e. steep slopes, cliffs and shallow slopes), in which case this change would suddenly become extremely useful (we could have /real/ maps then .

[Rubidium]

steep slopes, cliffs and shallow slopes

That requires map rotation to be useful, or you should like not being able to see what's behind a cliff. Have lots of fun implementing that first, or don't use cliffs. Not to mention that shallow slopes about doubles the amount of ground sprites (including rail and road) that would be needed and doubles the amount of foundation slopes. It'll also require surgery to the pathfinders and vehicle controllers to learn the shallow slopes. And then there's the matter of the many many things that rely on the tile height.

Furthermore drawing will get much more resource intensive with higher mountains as the viewport can contain more tiles of the map, so you need to query a considerably larger area of the map for things to draw.

Last but not least aircraft would need to fly significantly higher to not fly through the mountains, making their shadows appear far away from the aircraft and only making my previous point more severe; yup... you need to query all vehicles of a much larger area to see whether one is a plane that might be within the viewport.

[SirXavius]

Excellent points, rubidium. I would also love to play with a little bit more realism that is found in slopes and cliffs, but there's a lot more than just setting up new tiles....

Get ready for a LOT of work, in the form of code patches, ic111. The biggest and most immediate problem, as Rubi pointed out, is seeing behind topographical projections, a problem before you've even started a game. You must achieve a new way to manipulate transparency (based on x/y rather than z axis), or be able to rotate the map.

We wish you the best, if you can do it! (Just be ready for a letdown of realism -- we've all had to face it!)

[CommanderZ]

steep slopes, cliffs and shallow slopes

That requires map rotation to be useful, or you should like not being able to see what's behind a cliff. Have lots of fun implementing that first, or don't use cliffs. Not to mention that shallow slopes about doubles the amount of ground sprites (including rail and road) that would be needed and doubles the amount of foundation slopes. It'll also require surgery to the pathfinders and vehicle controllers to learn the shallow slopes. And then there's the matter of the many many things that rely on the tile height.

Furthermore drawing will get much more resource intensive with higher mountains as the viewport can contain more tiles of the map, so you need to query a considerably larger area of the map for things to draw.

Last but not least aircraft would need to fly significantly higher to not fly through the mountains, making their shadows appear far away from the aircraft and only making my previous point more severe; yup... you need to query all vehicles of a much larger area to see whether one is a plane that might be within the viewport.

I don't quite get how would higher mountains increase number of rendered tiles in a viewport enough to make a significantly parformance difference.

Non-technical point - but what would more height levels gain us?

A possibility to have really height varied maps. The height 15 mpuntain in OTTD is not really anything more than little hill when compared to something what would 50 levels high mountain be. Nobody says there would have to be such mountains 50 tiles from sea (thus making there a long 45 degree slope), but having a terrain slowly rising to such heights across let's say 200 tiles...that would be awesome.

PS: I'm not speaking about cliffs at all, just about the height levels.

[Rubidium]

I don't quite get how would higher mountains increase number of rendered tiles in a viewport enough to make a significantly parformance difference.

It's quite simple; a normal tile is 32 pixels high. A heightlevel is 8 pixels. A tile can change 2 heightlevels with 'steep slopes', so 16 pixels. This means that steep sloped tiles (sloping down to north) are visually 16 pixels high, one sloping down to the south is visually 48 pixels.

Assume a window of 640 pixels high (which is relative small). Without slopes there can be 20 tiles (top to bottom) shown. With 16 heightlevels with a slope down to the north we "gain" 16*8 pixels, which means that there can be up to 24 tiles top to bottom. With a 640 pixels and steep slopes you can place 640/16 = 40 tiles in the same viewport (with a total heightlevel difference of 80), which is almost the double.

But there is more... buildings on tiles south of the bottom of the viewport can be shown within the viewport, so we need to query those. As building can become pretty high (easily more than 230 pixels in TTRS), but let's assume 240 pixels for now. That would mean that it could be within the viewport when 240/16 = 15 steep sloped tiles are involved, which means 30 heightlevels. So even in this case for the original case less tiles need to be considered (as there can't be only 8 subsequent steep slopes). And again a considerably larger area (almost twice as large) needs to be tested.

So to sum up with 128 heightlevels an area roughly twice the size would need to be queried for drawing.

[ic111]

First: I am not talking about steep slopes. I just talking about increasing the allowed number of height levels. I don't want to touch the basic ideas of geometry in this game. (ok, having steep slopes would be cool, but I don't see how one can implement them without working for several months or years and ending up with another game).

For what type of scenario do I want to use them? I usually play using some extra rule to myself - a railway may not ascend by more than e.g. 16 percent (or in other words, you need 5 flat tiles between climbing up two heightlevels). This way, you can build pretty realistic mountain railways - beside the fact that I am ways too fast at the upper end of my mountains...

I think I start the following way: I'll put an appropriate field into the TileExtended data structure. Then I'll introduce some configuration setting "Allow mountains higher than height 16?". If yes, my new field is used for height level information, if no the traditional field in the Tile data structure. Probably this makes it easier for me too, because I don't need to break the existing code while implementing this.

In the end one can decide wether to keep this solution or to make high mountains standard (i.e. removing the possibility to choose).

[Rubidium]

First: I am not talking about steep slopes. I just talking about increasing the allowed number of height levels. I don't want to touch the basic ideas of geometry in this game. (ok, having steep slopes would be cool, but I don't see how one can implement them without working for several months or years and ending up with another game).

There are already steep slopes in OpenTTD; slopes 23, 27, 29 and 30 in http://vcs.openttd.org/svn/browser/trunk/docs/tileh.png are called steep slopes.

[michael blunck]

[more height levels]

It would be interesting to have (at least?) two depths of water. This would allow more interesting ship handling. E.g., large ships would need "deep" water, but coasters may travel in "shallow" waters as well. And we could have underwater tunnels in shallow water. All this would need underwater "landscaping" too, i.e. transforming shallow to deep water and vice versa. This could/should be a very expensive operation.

regards
Michael

[andythenorth]

It would be interesting to have (at least?) two depths of water. This would allow more interesting ship handling. E.g., large ships would need "deep" water, but coasters may travel in "shallow" waters as well...all this would need underwater "landscaping" too, i.e. transforming shallow to deep water and vice versa. This could/should be a very expensive operation.

It would also give your dredger a purpose. Although soon you may not be the only one who's drawn a dredger.

cheers,

Andy

[michael blunck]

It would also give your dredger a purpose.

I doubt that. Same for my track laying machinery.

Although soon you may not be the only one who's drawn a dredger.

Ah! An old-fashioned bucket-chain dredger with animation and original sound! That´s good news indeed.

BTW, how´s coding?

regards
Michael

[boekabart]

It would be interesting to have (at least?) two depths of water. This would allow more interesting ship handling. E.g., large ships would need "deep" water, but coasters may travel in "shallow" waters as well. And we could have underwater tunnels in shallow water. All this would need underwater "landscaping" too, i.e. transforming shallow to deep water and vice versa. This could/should be a very expensive operation.

That patch exists/ed: http://www.tt-forums.net/viewtopic.php?f=33&t=31576 . Needs updating though I suppose - for which I myself do not currently have the time. It _was_ very mature though.

[ic111]

Coding is ok, I have seen my first hill of height 20 in the scenario editor yesterday.

I have added a new configuration setting allow_more_heightlevels. Now, I have to take care about this variable being treated correctly, e.g. when changing game state. This leads me to the following questions:

(1) Am I right, that _settings_newgame stores the settings as they are currently configured in the menus, whereas _settings_game stores the settings used for the currently active game?
(2) In detail, does the intro game run using _settings_game?
(3) What happens when I alter a settings in-game? Do I edit _settings_newgame or _settings_game in that situation, and if the former is true, how does this affect _settings_game?
(4) Is it possible to allow changes of a setting only from the main game menu, not from inside the scenario editor or the game?

[michael blunck]

["deep water"]
That patch exists/ed: http://www.tt-forums.net/viewtopic.php?f=33&t=31576 . Needs updating though I suppose - for which I myself do not currently have the time. It _was_ very mature though.

Very interesting. Although a bit irritating with the number of different concepts (deep water, flooding, rivers, ...)

Some questions:

- what is

-- raised sea floor
-- sea level is 0
-- raised sea level

?

Does have "deeper sea" any effect on ship moving? Or could that be (easily) introduced? We already have something similar (at least in TTDPatch) where ships may have different speeds in canals/rivers and sea.

regards
Michael

[boekabart]

Some questions:

I agree, the patch grew too much. But about the deep water part of it:
"Sea level" is the elevation 'just above' which the sea level is: default/old situation would be 0, meaning it looks like level 0 and floods level 0.
"Raised sea floor" is a concept for the terrain generation: either it uses the normal terragen but with a higher sea level (giving you smaller land mass AND seas with varying depth, making it hard to build tunnels since you often will have to raise underwater land in order to make 'room' for a tunnel) OR it just raises the entire generated terrain by 'sea level', this does not change the way the terrain looks (same land mass, just lower (flattened) peaks), and you'll have a nice layer of sand on the sea bottom to dig your tunnels through. All sea will still be 0-deep.
I hope that explains
Currently there is 0 effect on ship movement, but IMHO if you'd want that, it would be necessary to have different sprites for shallow and deep water; currently you can't tell the depth without enabling transparency.

[michael blunck]

[...]
Currently there is 0 effect on ship movement, but IMHO if you'd want that, it would be necessary to have different sprites for shallow and deep water; currently you can't tell the depth without enabling transparency.

Your solution for showing underwater terrain ("transparency") looks quite good. For the normal (non-transparent mode) water representation a re-colouring (resp a different "water cycle") of water tiles could be a possible solution, although it may not be that easy. I´ll have a look into it.

Thanks for the explanation.

regards
Michael

[Zephyris]

Dithered transparency could work quite well... ie. a mostly transparent flat tile at z=0 with the action colours then a seabed tile drawn at the appropriate depth beneath it.

[el koeno]

I like the idea of more height levels. But IMO we don't need a whole lot. On mountains maps, with Pikka's modified construction costs and weight multiplier x7 I hardly ever reach the tops of mountains as it is.

Underwater levels I like as well. Perhaps trying to code one thing at a time is easier though. Still here's some ideas on that:
-Bridges could have maximum height. So there'd be a cheap concrete one which could only be built 1 tile high, whereas suspension bridges could be built over huge depths. Perhaps costs could be modified as well.
-Some effect on ships would be cool; you could even try to simulate sea-going vessels that could handle deeper waters than non-sea worthy vessels (which in turn would be cheaper).

Okay, those last two ideas were pretty unrealistic I guess, but I thought I'd just mention them. Who knows what might happen.