Store heights of terrain as float (get "limitation ~2 km" away)

#1 It would be great, but keeping compatibility.

#2 Just inherit from the current terrain class and make the changes - call it TerrainBlockEx or something and there is no breakage. All existing terrains use TerrainBlock and if you want the new terrain you use TerrainBlockEx (or whatever).

#3 Richard, it's good advice, but it had the misfortune to differ from the current approach: see TerrainFile::load() and save(). To start, I will add the "not limitation heights" by analogy (with a built-in versions).

#4 It would be greate to get limatation away!

#5 Actually, looking at TerrainFile::load() it appears that they did the whole "if this is version 3, do this, then if this is version 5 discard half of that and then do this other thing" bit - not great.

Perhaps there should be separate functions that handle each case based on the version of the terrain - so that TerrainFile::load() calls TerrainFile::_loadV3() or TerrainFile::_loadV5() depending on the need. ::save() looks leaner - apparently just dumps the terrain right out, no need to check anything.

#6 Well, I did the natural heights, as promised.

Pull request #567.
Demo level and video.

The old versions of terrains are supported.

#7 Yes sir. Good one!

One question, how do you build new heights terrain file? From a image file? In this case, if I remember well, it uses only 8 bits of height resolution.

What I'll do, whenever I have time... is implement the creation of terrain file from a GRD format file directly from the editor.

Thank you!

#8 > ... it uses only 8 bits of height resolution.
It isn't quite correct, sir. T3D understand an R5G6B5 format. See level / file "(4096x~330480m 0-8796m).#.png".

#9 Thanks, your are right!

#10 Thank you Andrey for your contributions and fixes. With just a little more patience from everyone I'm sure we'll be seeing quite a number of these new pull requests folded into the development branch.

#11 Very nice! Thanks man!