More height levels (in trunk since r27010)

[CommanderZ]

I tried to study the glitches a bit more. Here is a shot:

Sondston Transport, 21st Mar 1950.png

(162.92 KiB) Downloaded 100 times

There is a parfectly straight piece of track with a pinky train on it. The transmitter on the right side of the shot is at level 31, the upper track is correct (it seamlessly continues to right down to the water level), the bottom one is just a glitch. It is shifted once again by 255 pixels.

[planetmaker]

must be that because it gives no errors here.
i only extended the array.
nothing else.
is somebody else having problems??
expect a new patch very soon.
did you aply the other patches too?

The error happened when I applied it alone. It's fine, if applied on top. Sorry.

[ic111]

I guess some trouble might be caused by variable overflows - devs seem to use as small integers as possible, so where (u)int8 was sufficient on height 15, it might be too small for calculations with height 40.

EDIT: Additional infirmation to the glich with houses I presented in the previous post - the offset of their sprites over where they should be is 255 pixels, independently of the height. Affects all houses above level 31.

Seems that you are right. Looking into viewport.cpp (struct TileSpriteToDraw) and sprite.h (DrawTileSeqStruct), z always is saved as a byte. Combined with the fact that TILE_HEIGHT is defined to be 8 pixels, this means that we get glitches when the height of a tile exceeds 255 / 8 = 31 (rounded down). And this is exactly what happens.

So I will try to find those places and replace the 8 byte datatypes by something bigger.

[CommanderZ]

The game crashes while generating a 2048*2048*256 map (see the attachment). Am I hitting some limitation?

I was just trying if determining the maxinum height for the generator could work as "smaller dimension divided by eight". It works for all maps until 2048. 2048*1024*128 works fine. Maybe I should cap the height to 128?

EDIT: Now it crashed on 1024*1024*128 too

[ChillCore]

ah yes.
that one.

edit:
reply removed
read below
edit 2: added please in line below . i did not mean to be demanding. sorry.
/edit

in the meantime can someone please translate for me the following hex codes:

#99cccc
#9999cc
#cccc99
#cccccc

first one to blend with last greens.
last ones with the grays.
maybe extend the grays just a little
(instead of going beyond white)
or does somebody think... YUCK !
i wont be offended its just a suggestion.
please tell.

attached diff needs the mainpatch !
it does not work standalone.
it is intended to be merged with the rest of this patch when im done.
and for now i am not done...
enjoy.

[Terkhen]

I've been able to generate 8192 x 4096 x 128 maps using this patch and Bilbo's extra large maps patch, and I never had any problems...

[ic111]

The reason for the crash reported above is that an assertion in the old terraforming code fails. However, at least in usual terraforming this code is no longer used as of version 2 of my patch.

So either the more heightlevels patch version 2 is not installed properly or the map generator still calls this code.

Can you give us a stacktrace of that crash?

[CommanderZ]

Ahh, sorry, I didn't realize it might be already fixed, I don't have the newest version of the patch. I will try it the updated version right now.

[ChillCore]

i was thinking you guys had to do it again...
well i was in the assumption CommanderZ had version 2 in...

[CommanderZ]

The updated version works correctly.

[ic111]

Hello,

this is release 3 of my more heightlevels patch. My tests with some
city at heightlevel 53, with trains and busses and industries are
quite ok.

What's new?
The glitches are almost history. There where two main reasons for
them:

First, frequently the z coordinate was saved in a byte. Occasionally,
the old code even casted a int to a byte for one call of some helper
function and continued operating on ints afterwards. Hmm... I tried
to find all those places and replaced byte with int32.

If you encounter glitches where something located above height level
32 is painted too low, this is probably the reason.

Second, in the old code when painting the landscape, the heightlevel
was treated by (a) looking which tiles would be at sea level at the
edges of the to be painted area and (b) painting some fixed number of
tiles south of that area too. (if you have a look at the landscape,
by giving some tile height > 0, you shift the place where it must be
painted to the north).

I replaced this algorithm by a new one which also first determines
which tiles would be at the edges of the to be painted area assuming
sea level. But then, my algorithm has a look on the heights of the
tiles and by having this look, it determines which actually have to be
painted. For more information, have a look into the code.

Known bugs or things that still need to be done:
(1) The smoke of power plants e.g. at heightlevel 53 is painted too low.
(2) If you scroll across the map border in northwest, you will get
some glitches. Probably, under some circumstances the to be painted
area my algorithm determines is a bit too small. This can probably be
solved by applying an appropriate offset to some variable at a
to-be-searched place.
(3) I didn't touch airplanes. I think for their flying height, an
algorithm like "fly at the usual height if tile_height <= 15, else fly
at height tile_height + some_offset" would be appropriate.
(4) According to some forum entry above, there is a not-yet-finished
patch for the minimap. I didn't touch the minimap.
(5) I did not yet switch back to the old behaviour of levelling.
However, this is relatively simple - you just would have to call my
terraforming algorithm for each to-be-levelled tile individually and
ignore the errors for tiles where levelling is not possible.
(6) I had to make z_pos in struct Vehicle in vehicle_base.h an int32
(previously a byte). I don't know wether one has to write some
handling procedure for older safegames because of that.

Note that I will not be able to do anything with this patch during the
next few weeks. So if someone solves some of the problems above,
thanks, and feel free to publish version 4 / 5 / 6 / etc. of the
patch.

I think the patch is nearly finished now, except for some bugs and the
issues stated above, so it would be quite good if we could remove the
"nearly" in that sentence soon

[ChillCore]

thank you.

i will checkout your patch tonight.

as for my contribution...
i am sorry.
nature called and the little lady had a baby this week.
so its in and out of the hospital for now.
as for the rest of my free time i have been looking for that glitch bug...

you can ignore my colour question...
i found this neat colourcode list right where i should have started looking first,
in the docs folder ...
i feel silly...
but i have them now and i should find some time later this weekend.

once i have 128 colours
i will have a looksie on how to create dropdown boxes in the gui,
and have the game use the correct array when selecting desired height.

if somebody wants to jump in and give me a hand...
i would be delighted.
its not like im too lazy too learn...
i am afraid it will take me some time.
(reading and learning from other patches)

i need to learn how to create:

textfield in gui,
dropdowns, (choose height)
greyouts,(no 64 high on 64 square map, etc)
attach behaviour to all of this... (generate map with correct height and smallmapcolor)
and make it look correct.

maybe a bit to much in one go...

@ ic111:
(3) i agree. it would be nice to see planes change altitude
(4) in progress. i should finish my array127 by sunday.
then i start reading in order to create dropdown.

ps:
merry christmass to all.

[Zuu]

i need to learn how to create:

textfield in gui,

The text box widget type is called WWT_TEXTBOX if I recall correctly from memory. To use it you need to make the window class inherit from a special Query window class, instead of from the usual Window class. This is how the text-buffer that is used to store the string that users edit gets added to the window. As you probably see this is one of the reasons for the current limitation of only one text edit box per window.

In the constructor/destructor you will need to add code to lock the arrow keys from being used to pan the map. As you might know if a window with text box is open, all keyboard input is directed to the text box, and arrow keys need to be locked from being used to pan the map, instead users should be able to move the cursor in the text box.

Probably easiest is to read the code of an existing window that has a text box in it. Which you should do, as I have not checked it to make sure my statements are correct. I've been working with text edit boxes quite some the last half year with my filter sign list patch and later the widget focus patch. But I don't have every and all details in memory.

ps:
merry christmass to all.

Merry christmass you too

[Terkhen]

Well, this is getting better and better!

I did a quick test at height 125 and every graphical glitch (except those mentioned by ic111 in his post) seems to be fixed (I'll test it more deeply later). But I found a big bug that seems to be in the raise/lower land new algorithm... You can raise all the land you want: you will never get a "Not enough cash" error.

[ic111]

Well, this is getting better and better!

I did a quick test at height 125 and every graphical glitch (except those mentioned by ic111 in his post) seems to be fixed (I'll test it more deeply later). But I found a big bug that seems to be in the raise/lower land new algorithm... You can raise all the land you want: you will never get a "Not enough cash" error.

Oh, seems that I tested too much in the editor instead of in the game. Probably a check in terraform() is needed, before terraforming is actually performed according to the information collected before.

[ChillCore]

as requested by ic111 here is version 4.

what is in this version 4?
- version 3 by ic111.
- version3 includes moreheights-withheightmaps by Terkhen.
- tgp adaptor by CommanderZ.
- height_color array 15, 31, 63 and 127 for smallmap (not coded yet)
array 127 is currently used. please read comments in smallmap_gui.cpp for more info.

what have i changed:

- version 3-> no changes.
- heightmaps ->now set to load heightmaps at level 128.
- tgp adaptor-> no changes: WIP (as stated before by CommanderZ)
- smallmap colour array:
-> extended to 127 colours.
-> new feature: flooding_danger_flash at level 0. (again read comments in smallmap_gui.cpp please)

sorry for short post but i am a bit tired.

@ Zuu:
thank you for your pointers.
they will come in handy.

edit 1:
hmm. posting when tired is not good.
i forgot to credit someone, if not more than 1 person.
/me re-reads thread from page 1...take notes... then comes back to edit some more
edit2:
sorry Terkhen.
post updated.

[CommanderZ]

I will post new version of the tgp patch once it
can generate all map sizes correctly, for now it
works only for sizes <= 512, maps 1024 and larger
do unpretty things.

Btw does the patch keep track of what current highest
height is? then you could make the minimap adapt to the
current map height - it would show level 0 as green and
the highest level as yellow (or what color it is), the rest
would be calculated between these two.

[ChillCore]

Quote: CommanderZ said:
Btw does the patch keep track of what current highest
height is? then you could make the minimap adapt to the
current map height - it would show level 0 as green and
the highest level as yellow (or what color it is), the rest
would be calculated between these two.
/Quote.

@CommanderZ :
actually the patch does keep track of highest height.
twice, independant of one another:
that is, in regards to generation of terrain.

first time in tgp.cpp : MAX_TGEN_HEIGHT = value
second in heightmap.cpp. : line 354 (see comment at end of line)

in both cases you can still build higher if you want to do so.
(imo: the player should decide if he does that or not. no limits.)
for both cases i/we/somebody could attach a different array_to_use.
to clarify:
the version 4 i posted:
loads heightmaps at 128 (127 ?) (defined in heightmap.cpp)
but still generates a map at 63 (defined in tgp.cpp)
----
the calculating colours bit has crossed my mind ...
but: (why is there always a but?)
- on my quest exploring colors i have encounterd some (gr)action_colours.
can an algorithm cope with those?
or do you know somebody who can filter them out with an algorithm ?
also the brown-, blue-, red shades (and everything in between) ?
-also note that sometimes: "the next value" != "the next/desired shade".
/@CommanderZ

i have been thinking a bit about how to handle correct array use.

case 1: landgeneration
--------------------------
solution a and b.

a. extend selection box (both on new game and in scenario editor)
-verry flat
-flat
-hilly
-mountanious
-32
-64
-128
- ...
and attach colour_array_to_use here.

b. make MAX_TGEN_HEIGHT variable and selectable in advanced settings
as explained for loading heightmaps.(see case 2)
and have flat,hilly etc. calculated against this value (the way it is now)

both solutions are possible.
b would be my preffered way.

case 2: loading heightmaps:
---------------------------
there is already a button in advanced settings gui.
on is allow higher than 16 levels
off is do not allow higher levels.
dependant on this setting the correct height is generated (16 or other).
attached to this button is the loading heightmap_at_level_other behaviour in heightmap.cpp,
with an if else statement.
this if else statement decides the value of other.

maybe this statement can be extended and selectable in advanced settings gui.
this would need a select heightmap_height button to be created as proposed below

the same can be aplied for case_1_solution_b above.
(add an if else to MAX_TGEN_HEIGHT in tgp.cpp ?)

proposed advanced setting gui:
[textfield][setting/value/dropdown?]
-----------------------------------------
- [allow more than 16 levels] [on/off] (is there allready)
- [load Heightmap_height] [original/32/64/128/...](auto-select original if above setting is off)
- [MAX_TGEN_HEIGHT] [original/32/64/128/...](auto-select original if first setting is off)

- attach behaviour to decide what color array to use to the two new options(invisible to user)

so far my proposal for now.

as for array 255:
it will be very hard to find more shades.
there is already:

- white for rails.
- red and black for towns and industries.
- blue for rivers and sea.
- i tested some browns and YUK...(at least not where i had put them)

all these colours(except brown) have to show up at the same time.
and still have to have enough contrast to see what is located where.
also, as you can see when testing,
the pale-greens are kinda hard to distinguish.
so instead of adding shades there i should delete some ...
i still have room for expansion, only i do not know how much.

how would you people feel to use array 127 for level 128 and also for level 256?
(1 colour two levels)

[CommanderZ]

actually the patch does keep track of highest height.
twice, independant of one another:
that is, in regards to generation of terrain.

first time in tgp.cpp : MAX_TGEN_HEIGHT = value
second in heightmap.cpp. : line 354 (see comment at end of line)

in both cases you can still build higher if you want to do so.
(imo: the player should decide if he does that or not. no limits.)
for both cases i/we/somebody could attach a different array_to_use.
to clarify:
the version 4 i posted:
loads heightmaps at 128 (127 ?) (defined in heightmap.cpp)
but still generates a map at 63 (defined in tgp.cpp)

This wasn't exactly what I meant. I meant if it stores the highest height really used, so the minimap would adapt to the changes of the heigh field during game too - for example - player would generate quite flat map with heights 0-10. The minimap would show height 1 as green and height 10 as yellow. But then the player goes mad and makes a 200 tiles high pyramid of dirt. The scale would shift and 10 would be still quite green and yellowish colors would start apearing at height 120 or so.

This is to make the minimap useful as flatmaps too. I guess played classical ttd map with 16 heights and the minimap would be optimized for 127, all the minimap would be flat green.

The array could be used for 8bpp blitter, but for the 32bpp you should use some smooth color gradient algorithm.

proposed advanced setting gui:
[textfield][setting/value/dropdown?]
-----------------------------------------
- [allow more than 16 levels] [on/off] (is there allready)
- [load Heightmap_height] [original/32/64/128/...](auto-select original if above setting is off)
- [MAX_TGEN_HEIGHT] [original/32/64/128/...](auto-select original if first setting is off)

The height scale for heightmap generation should be in the heightmap import window imo.

For the tgen setting, it would be better to use multiplier, because the base height bounds will be calculated from the size of the map (one eighth of the smaller map dimension currently). the multiplier could have these values: 1/16, 1/8, 1/4, 1/2, 1, 2, 4, 8. I need it to stay in powers of two for now. I think this settig should be in the map generation window (as all the settings affecting map generation are there).

PS: Please use the Quote tag (and other formatting) where necessary, it makes the posts much more pleasant to read.

[ChillCore]

indeed playing 16 high witch 127 array looks like ****.
the other way round is even worse.

hmm auto-scaling heightmap_colours...
sounds great, but is out of my league.
if somebody can do that... i would like that very much.
that way we would only need 1 array and we keep code compacter.

as for the what to put where...
i am learning.
there is so much...
but i am not complaining.

i will not change stuff just like that ...
i watch and learn ...
it will be obvious for you what to do when the time comes, i guess...
feel free to adapt my arrays, even delete15, 31, 63, if no longer needed.
even if none used anymore i will not cry because i have learned something new.

Edit:
I am sorry.
I keep JavaScript and ActiveX disabled.
Bassicly all other security settings are off too.
So no quotes for me.
Even smilies do not work for me.
As a pleasant side effect.(for me). Byebye google ads.
I will try harder to keep my posts more pleasant to read.