More height levels (in trunk since r27010)

[Tafidis]

@Eddi: Thanks for the replies

As always, a big improvement like this may exaggerate other problems that were so far insignificant. Case in point: cities on mountaintops! It looks even more silly now than before (I know some may like it and see it as a challenge, but I believe most would agree it looks weird). No need to provide screenshot either. Just imagine a mountain with height 80 and a city on top, while the valley far below has a couple of villages next to each other. Maybe they try to avoid mosquitos lol.

I know it has nothing to do with this patch, but just putting it out there. Is it hard to have a "maximum height for town origin tile" during map generation?

[ic111]

Actually, I already thought about adjusting the city placement generator a bit. This shouldn´t be too complicate. Probably an algorithm like:

(1) Choose tile by random
(2) Calculate min/max/average height of selected tiles in a grid around that tile
(3) Maybe take the presence of rivers into account
(4) Based on (2) and (3), and the height of the tile itself, calculate some probability that this is a valid place for a city, plus maybe a probability distribution for its size
(5) If Random() says yes, place it, otherwise try again elsewhere

should do the job.

Regarding (2), if the average and min height of tiles in a grid around a tile is not significantly smaller than the height of the tile itself, then chances are high that we are in a valley.

[Tafidis]

Your proposal is much more structured than mine. Instead of setting a hard limit, you instead have a probability distribution for both (a) existence (b) size of the town [perhaps (c) gaining the "city" attribute could fit here too, perhaps?].
The probability itself is based on height, flatness, and rivers.

I like the detail, however I am not sure what the effect of flatness (valley) and rivers should be. I think it is ok for towns to be built in sloped areas, there are towns like that. So I don't know if this should have an effect on the existence, but maybe on the size. One thing that I can imagine happening (but haven't seen yet), is when towns expand upwards on slopes along a single road. With mhl, this could turn into a "stairway to heaven" town layout. Again, of course, this a totally separate problem.

Rivers should actually add to the probability if one thinks more in CIV game terms, at least!

[romazoon]

a small question regarding mhl, would it be a reasonable to allow editing the max height after creation of the game ? i actually see the option greyed out in the advanced parameter (and i could swear it wasn't greyed out before...but i might have dreamed it).

i m in the process of editing a scenario and i would like very much the ability to increase the heights of the peaks( wich appear like large plateau right now)

so finally i just want to know if that greyed out parameter will come to use one day, or not

[ic111]

I like the detail, however I am not sure what the effect of flatness (valley) and rivers should be. I think it is ok for towns to be built in sloped areas, there are towns like that. So I don't know if this should have an effect on the existence, but maybe on the size. One thing that I can imagine happening (but haven't seen yet), is when towns expand upwards on slopes along a single road. With mhl, this could turn into a "stairway to heaven" town layout. Again, of course, this a totally separate problem.

Well, I think those towns that choose the one flat tile in a big sloped area are not quite well-positioned, they should gain low probability. Big cities are often near some river, so a river should increase the probability of a big city significantly. Also, cities are quite seldom founded at the top of big mountains, e.g. in Europe, big cities are always below 1000m, and small cities below 2000m, and the area above 2000m hasn´t any cities at all. So if e.g. heightlevel 60 is equivalent to 3000m, then I wouldn´t expect any city above, say, heightlevel 40.

Just some thoughts, but IMHO the important point in terms of development is, that all these conditions can be decided based on "choose a random tile, inspect its neighborhood, decide wether you take it". This should make things relatively simple in terms of development.

One additional, a bit more sophisticated point might be, make small cities more probable, if a big city isn´t too far away, i.e. form some suburbs.

a small question regarding mhl, would it be a reasonable to allow editing the max height after creation of the game ? i actually see the option greyed out in the advanced parameter (and i could swear it wasn't greyed out before...but i might have dreamed it).

It is possible in the Cheat window. But only there, as it is a bit tricky, in particular NewGrf state has to be resetted for altering the max height.

[romazoon]

It is possible in the Cheat window. But only there, as it is a bit tricky, in particular NewGrf state has to be resetted for altering the max height.

thanks for the fast answer ! now is there a console command to reset the newgrf state after using the cheat ? (or waht do i have to do ? )


hmm....and how do i open cheat mode in the scenario editor ? (i know i can launch scn as a game, save at start, then rename the .sav to scn...but i find this a bit ennoying...as this cheat (of changing maxheight) seems tailored for scenario editing.

[ic111]

It is possible in the Cheat window. But only there, as it is a bit tricky, in particular NewGrf state has to be resetted for altering the max height.

thanks for the fast answer ! now is there a console command to reset the newgrf state after using the cheat ? (or waht do i have to do ? )

No, the NewGrf state is resetted automatically by the cheat, this was just background info why it has become a cheat, and not a setting.

hmm....and how do i open cheat mode in the scenario editor ? (i know i can launch scn as a game, save at start, then rename the .sav to scn...but i find this a bit ennoying...as this cheat (of changing maxheight) seems tailored for scenario editing.

Arg, I think you are right, the ususal key combination doesn´t seem to work in the editor.

[Espee]

Wow, that was a quick reply! Talk about great customer service...

I'm not playing a customer support - I'm just another player who happen to know the answer to that particular question, and I just happened to read your post at the right time!

OK, but I didn't mean to insinuate that it was your or anyone else's duty to be standing by to answer questions. I just appreciated the quick reply, that's all. thank you.

how will this be implemented? The current 0-15 height range appears to be determined by dividing the (average) heightmap pixel brightness (8-bit value) by 16 and rounding down to the nearest integer value. Will be be able to change that dividing value of 16 to other values (8,4,2) and get 32, 64, 128 height levels respectively?

When you're loading the heightmap, the World Generation window asks you what you want as the maximum map height to be. You can select any number between 15 and 255. Then the map generator will scale the terrain from sea level to the max height you specified.

OK, I went ahead and downloaded r27047 onto my XP laptop and tested some of my custom heightmaps on it, and it appears that the map height for a given tile = (selected max height/256) * pixel value. Now I have been using B&W heightmaps which have seemed to work for my purpose BUT with the greater differentiation of layers, it is making it much harder to see subtle changes in lower elevation with my chosen editing tool. I noticed that others are using colored heightmaps (blue for water, green for lower elevations, yellow or off white for higher elevations), so I have been trying to figure out how to implement this RGB-wise. I assumed that water at sea level had pixels with an RGB value (24 bits) of 0x0000FF, the highest points with max red and green (0xFFFF??) to create yellow, but the middle values would have mainly green. I tried splitting my gray scale map, which has a full range of colors (00-FF) into 3 color channels, then loading it into a scenario with the max height set to a value of 60. I got the following results: the hills on the red map are truncated to 20, the green are 30, and the blue are 10, with water levels significantly different, as if the red and blue channels were lowered in relation to the green by the same amounts as the highest peaks. Can someone please point me to the algorithm that converts RGB maps into the appropriate heights?

[Eddi]

coloured heightmaps get converted into greyscale before OpenTTD processes them. so only the brightness counts, not whether it's blue or green or whatever.

[Pyoro]

I noticed that others are using colored heightmaps (blue for water, green for lower elevations, yellow or off white for higher elevations), so I have been trying to figure out how to implement this RGB-wise.

You aren't talking about those screenshots on the last few pages, are you? Those are just minimap screenshots, not heightmaps you'd import into the game.

[Espee]

coloured heightmaps get converted into greyscale before OpenTTD processes them. so only the brightness counts, not whether it's blue or green or whatever.

OK, thanks, so here's my question: when these maps are turned into grayscale, is the new value the average of all 3 layers or some other formula? Again, I ask this question because I tried splitting a grayscale map into the 3 color components and got different results for each one.

[Alberth]

/**
* Convert RGB colours to Grayscale using 29.9% Red, 58.7% Green, 11.4% Blue
* (average luminosity formula, NTSC Colour Space)
*/
static inline byte RGBToGrayscale(byte red, byte green, byte blue)
{
/* To avoid doubles and stuff, multiply it with a total of 65536 (16bits), then
* divide by it to normalize the value to a byte again. */
return ((red * 19595) + (green * 38470) + (blue * 7471)) / 65536;
}

[Espee]

/**
* Convert RGB colours to Grayscale using 29.9% Red, 58.7% Green, 11.4% Blue
* (average luminosity formula, NTSC Colour Space)
*/
static inline byte RGBToGrayscale(byte red, byte green, byte blue)
{
/* To avoid doubles and stuff, multiply it with a total of 65536 (16bits), then
* divide by it to normalize the value to a byte again. */
return ((red * 19595) + (green * 38470) + (blue * 7471)) / 65536;
}

Got it, thanks - that seems consistent with what I have seen in my testing. Nice sample of C coding there...

[Alberth]

Got it, thanks - that seems consistent with what I have seen in my testing. Nice sample of C coding there...

Ha, it's probably in there for ages

I looked it up for you, and it was added in r5949, in August 2006, so 8 years old

[peter1138]

ic111:

Flickering of tall buildings (http://bugs.openttd.org/task/6156) occurs since:

r26899 | rubidium | 2014-09-21 18:27:37 +0100 (Sun, 21 Sep 2014) | 2 lines
-Codechange: reduce the amount of tiles that needs to be drawn by taking the height of tiles into account instead of drawing way too many (ic111)

Seems it's overly optimistic?

[ic111]

This is the piece of code in viewport.cpp one has to adapt:

Code: Select all

	/* The upper and lower edge of the viewport part to paint. Add some number
	 * of pixels to the lower end in order to ensure that we also take tiles
	 * south of the given area, but with high buildings intersecting the area.
	 * Subtract some pixels from the upper end in order to avoid glitches at the
	 * upper end of the top be painted area. */
	int viewport_top = _vd.dpi.top - 16;
	int viewport_bottom = _vd.dpi.top + _vd.dpi.height + 116;

More, precisely, the 116 pixels doesn´t seem to suffice for that building. I think I copied that number from the old code, but there might have been some extra margin I didn´t recognize.

Thus, it all reduces to the question: How high is a building in OpenTTD allowed to be? I raised this question already when we finally made MHL ready for trunk, but I didn´t get an answer then.

Once this number is known, one has to adapt that constant, and to get rid of that issue once and forever, test with a building that has exactly that height (maybe one has to shift things by some pixels because the term "height of building" and my algorithm refer to different baselines).

[peter1138]

Well there's an old value of 241, but I don't know if it's scaled or not, and it's not exactly related. Certainly replacing 116 with 241 doesn't actually fix the flickering issue.

[ic111]

No, I doubt 241 is the number we search...

Certainly replacing 116 with 241 doesn't actually fix the flickering issue.

Now I am surprised. What makes you so sure about that? Did you test that? If yes, I miss something, if not:

My reasoning is, that 241 is a way too safe bound, I wouldn´t expect anything bad happening with 241. For me, the question is rather, do we need something like 130, or 150, or whatever?

And this, in the end, is an issue against the NewGrf specification. Somewhere, a maximum height of a building must be defined. (and BTW such a bound implicitely existed in the old code as well).

If someone can provide me a worst-case NewGRF with such a max-height-building (maybe just for test purposes, something easily buildable like a very high station) then I could optimize this.

[ic111]

Hm, probably you are right. I just tested it with the savegame attached to the bug report.

My impression was that with 200, it happens less often, with 400 I wasn´t able to reproduce it at all. Nevertheless, what I saw is not consistent with the simple bound issue I first suspected.

Does anyone know, how repainting triggered by the animations those buildings have is handled? Is there anything the NewGRF can do wrong in terms of repainting an animated building?

[peter1138]

This is nothing to do with NewGRF, as the particular building I've noticed flicker is in the original base set -- the building with two pillars which supports a hanging centre section. There may be others.