More height levels (in trunk since r27010)

[ic111]

Just an updated version of the more heightlevels patch, with some rather minor adjustments to changes in trunk.

Have fun

[Ben_Robbins_]

Thanks a lot for this!

[ChillCore]

Same here, thank you for the update.

I was having a quick browse and noticed something wrong in patch 30.
I have not compiled but I expect to see glitches in game if I do.

This code in table/sprites.h:

Code: Select all

@@ -565,6 +565,8 @@
 static const SpriteID SPR_FLAT_2_QUART_SNOW_DESERT_TILE = 4512;
 static const SpriteID SPR_FLAT_3_QUART_SNOW_DESERT_TILE = 4531;
 static const SpriteID SPR_FLAT_SNOW_DESERT_TILE         = 4550;
+/* Blacktiles all slopes. */
+static const SpriteID SPR_FLAT_BLACKTILES               = SPR_OPENTTD_BASE + 168;
 
 /* Hedge, Farmland-fence sprites */
 static const SpriteID SPR_HEDGE_BUSHES            = 4090;

Should read like this:

Code: Select all

@@ -565,6 +565,8 @@
 static const SpriteID SPR_FLAT_2_QUART_SNOW_DESERT_TILE = 4512;
 static const SpriteID SPR_FLAT_3_QUART_SNOW_DESERT_TILE = 4531;
 static const SpriteID SPR_FLAT_SNOW_DESERT_TILE         = 4550;
+/* Blacktiles all slopes. */
+static const SpriteID SPR_FLAT_BLACKTILES               = SPR_OPENTTD_BASE + 174;
 
 /* Hedge, Farmland-fence sprites */
 static const SpriteID SPR_HEDGE_BUSHES            = 4090;

If and when "static const uint16 OPENTTD_SPRITE_COUNT = 193;" needs adjusting (to play nicely with the newer version of OpenGFX) the line mentioned above must be updated arccordinly..

I am looking a bit further to see if anything else might be wrong.


ps:
Curse you ic111 for this update, you are making me consider putting my XP machine back online for a little while ...
^^^ Maybe it would be better if you keep in control from now on but on the other hand I do not know how much time you have available these days to push out updates.

[ic111]

You are right, I forgot to increase that counter also when adjusting the numbers to changes in trunk.

Is fixed.

Regarding updating the patch: Should basically be no problem for me, except if devs would make changes in trunk that really blow up major parts of this patch.

But I hope that won´t happen.

As long as only some small adjustments from time to time are necessary, this should be no problem. I just tend to only make such updates when there is a trigger for them, either me needing a version compatible with current trunk, or someone requesting it. I certainly do not actively check every week wether it still applies against trunk...

[kingrein]

May i have the binairies fir windows? I just cant get the compile environment working.

[planetmaker]

I would rather suggest something like

Code: Select all

diff --git a/src/table/sprites.h b/src/table/sprites.h
--- a/src/table/sprites.h
+++ b/src/table/sprites.h
@@ -57,6 +57,7 @@
 /** Extra graphic spritenumbers */
 static const SpriteID SPR_OPENTTD_BASE   = 4896;
 static const uint16 OPENTTD_SPRITE_COUNT = 174;
+static const uint16 OPENTTD_PATCH_COUNT  = 1;
 
 /* Halftile-selection sprites */
 static const SpriteID SPR_HALFTILE_SELECTION_FLAT = SPR_OPENTTD_BASE;
@@ -159,7 +160,8 @@
 
 static const SpriteID SPR_WINDOW_DEFSIZE             = SPR_OPENTTD_BASE + 168;
 
-static const SpriteID SPR_SIGNALS_BASE  = SPR_OPENTTD_BASE + OPENTTD_SPRITE_COUNT;
+static const SpriteID SPR_PATCH_BASE = SPR_OPENTTD_BASE + SPR_OPENTTD_SPRITE_COUNT;
+static const SpriteID SPR_SIGNALS_BASE  = SPR_PATCH_BASE + OPENTTD_PATCH_COUNT;
+/* Blacktiles all slopes. */
+static const SpriteID SPR_FLAT_BLACKTILES               = SPR_PATCH_BASE;
 
 static const uint16 PRESIGNAL_SPRITE_COUNT                   =  48;
 static const uint16 PRESIGNAL_AND_SEMAPHORE_SPRITE_COUNT     = 112;
 static const uint16 PRESIGNAL_SEMAPHORE_AND_PBS_SPRITE_COUNT = 240;

to reduce maintenance with the sprite numbers.

[ChillCore]

ic111,
I do not expect really big changes to happen anymore, unless Devs have a rabbit up their sleeves.
We already had those really big changes quite some time ago. (Disclaimer I have not yet looked at the rest of the code)
If that does happen you will not be alone up to the task prommised.
I will for the moment post fixed code when needed and we will see if I need to jump in posting patches or not.
The reason I would like for one of us to post is because that one, you or me, can keep track of what changed exactly more easily.



Kingrein,
unless someone beats me too it or my windows compiling environment is broken. I will post one tomorrow.
I am currently in the middle of downloading linux Mint 15, so I can not reboot in Xp for the next 35 hours (7.7KB/s, it does speed up from time to time so I am hoping it will be sooner then that).

Also, do not give up to soon. Can you compile clean trunk? If not focus on that first.
My first time, took me one week of messing about, buying a newer pc and then two more days to set up the environment (including downloading).
After that it was a breeze and has been most of the times.
There is a sticky where you can explain exactly what goes wrong.

[kyosuke1989]

Thumbs up for this patch! I hope this will eventually reach trunk. Does this latest patch version have 256 height levels?

Played few times with ChillCore's patchpack (this patch included), had fun with those mountains then

[ChillCore]

Ofcourse it has 256 height levels.

My patchack was created only to test this patch with some others ... it got slightly out of hand (the patchpack I mean).




Psssssst:
There is earlier in this thread a working binary that has a whole lot more heightlevels available; 1024 of them to be exact but it is buggy. (<- extension to the "kgat patchpack")
Be warned though it is rather unstable in places and to get there you need to make a map that is 8k by 8k tiles

[Phreeze]

ic111,

I am currently in the middle of downloading linux Mint 15, so I can not reboot in Xp for the next 35 hours (7.7KB/s, it does speed up from time to time so I am hoping it will be sooner then that).

tell us next time, someone will send you a dvd should be faster

[ChillCore]

Hehe thank you.

It is not like I was sitting there staring at the screen waiting for it to finish.
It was done somewhere in the middle of the night and I do have three machines that are happy to let me tinker with them too to keep me busy.

I still need to install the new version 2 times and I am doing a clean install of winXP and Win8 at the moment too as the new versions of openttd did not compile with my very old non-updated compiling environment (XP).
Lots of things to do in RL first, before the winter, but when I get back to coding I am going to save the sources on a homeserver (which I still need to buy) so down time should be pretty much a thing of the past.

I have Mint 15 running of an USB though and it still works when removing the HDD form the machine.

[SwissFan91]

It's brilliant to see this patch still alive - it is one of my favourites. Hopefully it will continue to keep up with trunk so when I release my mountain eye candy (pistes, cable cars etc.) then I can have 256 levels instead of just 13 or 15 or whatever the current limit is.

To conclude: a big thanks to the developers of this patch!

[RBC]

I would rather suggest something like
[...]
to reduce maintenance with the sprite numbers.

typo: SPR_OPENTTD_SPRITE_COUNT should be OPENTTD_SPRITE_COUNT

Code: Select all

diff --git a/src/table/sprites.h b/src/table/sprites.h
--- a/src/table/sprites.h
+++ b/src/table/sprites.h
@@ -57,6 +57,7 @@
 /** Extra graphic spritenumbers */
 static const SpriteID SPR_OPENTTD_BASE   = 4896;
 static const uint16 OPENTTD_SPRITE_COUNT = 175;
+static const uint16 OPENTTD_PATCH_COUNT  = 1;
 
 /* Halftile-selection sprites */
 static const SpriteID SPR_HALFTILE_SELECTION_FLAT = SPR_OPENTTD_BASE;
@@ -159,7 +160,8 @@
 
 static const SpriteID SPR_WINDOW_DEFSIZE             = SPR_OPENTTD_BASE + 168;
 
-static const SpriteID SPR_SIGNALS_BASE  = SPR_OPENTTD_BASE + OPENTTD_SPRITE_COUNT;
+static const SpriteID SPR_PATCH_BASE = SPR_OPENTTD_BASE + OPENTTD_SPRITE_COUNT;
+static const SpriteID SPR_SIGNALS_BASE  = SPR_PATCH_BASE + OPENTTD_PATCH_COUNT;
+/* Blacktiles all slopes. */
+static const SpriteID SPR_FLAT_BLACKTILES               = SPR_PATCH_BASE;
 
 static const uint16 PRESIGNAL_SPRITE_COUNT                   =  48;
 static const uint16 PRESIGNAL_AND_SEMAPHORE_SPRITE_COUNT     = 112;
 static const uint16 PRESIGNAL_SEMAPHORE_AND_PBS_SPRITE_COUNT = 240;

[ic111]

Just a quick update to current trunk.

Many thanks to devs for the (with respect to the parts of OpenTTD affected by this patch) quite stable codebase, updating was really easy this time

[ixcoder]

Hello there,

once more thank you for this patch. I am using it within Spring Patch Pack and YAPP. It makes it possible wo play with really heigh mountains.

I found an issue using theese when starting a game on a selfmade heightmap using one of these patch packs. It is located at the point of saving heightmaps. As far as I can see these do not support those heigt levels above 16.

See example results in attachments (made with Spring Patch Pack).

[kamnet]

It is because the import heightmap function doesn't support it.

[ChillCore]

I think it is the export function ixcoder is complaining about.

I used this one line fix in my patchpack ...

Code: Select all

diff --git a/src/screenshot.cpp b/src/screenshot.cpp
--- a/src/screenshot.cpp
+++ b/src/screenshot.cpp
@@ -792,7 +792,7 @@ static void HeightmapCallback(void *user
 	while (n > 0) {
 		TileIndex ti = TileXY(MapMaxX(), y);
 		for (uint x = MapMaxX(); true; x--) {
-			*buf = 16 * TileHeight(ti);
+			*buf = 1 * TileHeight(ti); // Todo: adjust to allow choosing generated height; 16 is trunk
 			buf++;
 			if (x == 0) break;
 			ti = TILE_ADDXY(ti, -1, 0);

Obviously the use of grayscale colours could/should (?not?) be extended (read: scaled based on certain variables) and the above is (?not?) a temp-fix.
I am not sure which way to go ...

[Eddi]

i have not looked at how this patch does things, but IMHO it should work like this: at start of a map, you select a maximum heightlevel (e.g. 8/16/32/64/128/256)besides the other factors like hilliness, and this setting is also used to define the scale factor for the heightmap export.

this way, you can load a heightmap saved with a different height scaling, without any modifications. (but going higher may leave you with weird edges, but the same thing is true if you load a heightmap with smaller resolution)

[ixcoder]

@ Chill: seems like you got my point.

Well, I have only very little knowledge about OTTD's source code. So I am talking from a user's point of view.

Taking a look to the .png file that is used to store height maps I can see a file using 8bpp. Therefore we should have 256 different values from black to white (0x00 to 0xFF). At the moment only 16 of these used. The height levels of heigher maps are stored as (height level) mod 16.

One solution might be to save heightmaps with a variable number of values. This number might be the lowest number to the power of two greater or eqal to the max height level used. --> n = 2^x & n >= max_height_level (n >= 16 would be a nice fallback for flat maps)

--> max_height = 0 .. 15 -> 16 values
max_height = 16 .. 31 -> 32 values
max_height = 32 .. 63 -> 64 values
and so on

Maybe the number of used values could be saved in that .png as well?

I think loading a heightmap with a different scaling as it was saved with result in the same problem as we have now when opening a usual 16 level heightmap.
Loading those height maps is not a problem as far as I can see. Right now this is running quiet nice when loading a heightmap with 265 different grey values used (created outside OTTD).

Just my 2ct

[planetmaker]

Just my personal opinion, without considering any UI things or integrations or possible scenario formats:

When it comes to importing a height map, it probably makes most sense to
* export heightmap such that the 0 ... MAX_HEIGHTLEVEL are mapped to the 0 ... 255 range
* import heightmap
** to allow selecting the maximum height generated (assuming by default 0 ... 255 range)
** optionally and additionally:
*** show actual range used in the image
*** allow to set thresholding for a lower and upper bound for the values to be considered. Use this range to create the game map with heights between 0 and MAX_HEIGHTLEVEL