News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

slopes patch

Started by kierongreen, June 01, 2020, 11:54:48 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ceeac

Quote from: kierongreen on June 30, 2020, 07:29:55 PMThanks ceaac in one sense I'm amazed those are the only warnings as for the last few months so many have been generated by trunk I've not been able to notice any in my own code! These do highlight an issue which will fix though.
Try adding -Wno-deprecated-copy.

kierongreen

#36
Quote from: ceeac on July 01, 2020, 07:40:06 AM
Try adding -Wno-deprecated-copy.
Thanks....

Quote from: makie on June 30, 2020, 08:22:15 PM
ok I understand. Then this here is not a solution for us, then pak128.german will remain at double heights.If the map generator can set slopes on rock faces. That would be great.
I intended this for loaded height maps.
I had built that in before. Look here:
https://www.simutrans-forum.de/mybb/showthread.php?tid=8964
Unfortunately, my patch not work anymore, since your patch.
You can also see, my need for a snow slope.

Try looking at https://simutrans-germany.com/files/upload/generate-lightmaps-markers-with-images.zip - this includes the lightmap program which is working on one of my computers at least but also generated markers and lightmap images for pak sizes 32, 64, 128, 192 and 256 for single and double heights. Note that the double height versions result in non-rectangular pak images I've no idea how these will work in game.

Edit - have a hunch there may be a problem here with 32 vs 64 bit compilation? The lightmap program uses longs and so on which might behave differently?

makie

The png looks fine.
I will try, this will take a while.

makie

#38
This is my version of the  lightmap generation program.
https://sourceforge.net/p/simutrans/code/HEAD/tree/tools/generate-lightmaps/generate_lightmaps_TH.cc
The tiles must be square for makeobj. In my case it must be packed with pak160. Maybe it have to be shift to the right position.
-------------------------------
there is a little problem with PAK160 size of the  generate_lightmaps



kierongreen

#39
Minor update to latest trunk - patch and associated files can be downloaded at https://simutrans-germany.com/files/upload/9169-triple-heights.zip


Have corrected some calculations relating to foundation images, and address issues raised by ceeac should now be addressed - for the line in brueckenboden there may be an error here in trunk as current trunk code only detects single height slopes I think:
Quote from: ceeac on June 30, 2020, 11:58:53 AM
Warnings when compiling with clang 10:

boden/brueckenboden.cc:42:49: warning: taking the absolute value of unsigned type 'uint8' (aka 'unsigned char') has no effect [-Wabsolute-value]
                        if(  (get_grund_hang() == slope_t::west  &&  abs(back_imageid) > 11)  ||  (get_grund_hang() == slope_t::north  &&  has_back_image(0))  ) {

boden/tunnelboden.cc:70:59: warning: taking the absolute value of unsigned type 'uint8' (aka 'unsigned char') has no effect [-Wabsolute-value]
                        if(  (ribi_type(get_grund_hang()) == ribi_t::east  &&  abs(back_imageid) > 11)  ||  (ribi_type(get_grund_hang()) == ribi_t::south  &&  has_back_image(0))  ) {
       
boden/grund.cc:736:21: warning: unused function 'get_back_image_from_diff' [-Wunused-function]
static inline uint8 get_back_image_from_diff(sint8 h1, sint8 h2)



Other issues/comments remain as per previous version:
savegame version is likely temporary, and while it works currently games might not be able to be loaded in future
While bridges can start or end on a triple height slope this just uses the double height slope images.
Tunnels must start from a single/double height slope (dependent on pakset conversion factor)
Fences/walls act slightly differently from before - now both can be present on a tile as they are calculated at draw time
Port images won't always display correctly (although these maybe needed more work anyway as the code was never really updated following the change to flat or differently sloped shorelines)
Scripting may not be updated to deal with revised constants associated with triple heights
Ways cannot be built on triple slopes (this is probably intended...)

There will also still likely be issues with trying to define ground images larger that the pakset size, and I would therefore continue to suggest that the patch is only used with half height paksets (will look into this now).

Again, unless you compile a triple height enabled pak you shouldn't see much in the way of differences in game.


Edit:
makie - would it be possible for you to send me the files you are using to put triple heights into the pak128.German so that I can test these please? Just the ones that have changed over a standard pak128.German install.

Edit 2:
add to the known issues that single height paks don't display correctly (will be fixed in next version)

kierongreen

For the benefit of really keen full-height pakset users here is a version of the patch that should work with these paksets. You will need to compile grounds with larger pak size than the rest of the pak (for pak128 it's pak160, pak64 would be pak80). Walls are untested as I didn't have suitable images to hand but I think they should work.

As an example here is a simple test with pak128.German



The code in this version is a bit of a hack and so may need tidying up if it is included in the main patch. I'm not sure how useful people will find this - there's still the issue with these paks that having triple heights hide areas of grounds, and visually it results in extremely steep slopes, also I have observed that full height paksets are even less likely to have triple heights generated on maps than half height ones due to the way heights are read from heightmaps. Still, feel free to play!

Attached is zip of patch only - you will need graphics and dats on this, you may be able to take these from the half height ones included in the post above, but some images will need altering to work with full heights.

makie

#41
interim result
the Basement / slope are not perfect

https://makie.de/Tri_Height.zip

The folder 160 has to be paked with PAK160

Beta 2.0 of the pak128.german for triple heights.
https://pak128-german.de/PAK128.german_VS2.0.beta_tri_h.zip

There is also two save-game in the zip. This are maps of germany with big mountains. As I imagine it. The coast is bugy the error is known.
But this save-game abort when you move to fast. I think it is a timing problem. I don´t know why. Ok the maps a really big, but it is necessary, if there should be towns have space in valleys between the mountains.

This is with double height:

This is the same, with triple height

As you can see there are less rockface with triple height.
Some can remember this thread a year ago:
https://www.simutrans-forum.de/mybb/showthread.php?tid=8964

kierongreen

Thanks mackie - the Alps in those saved games are certainly one way to test how mountains are displayed! Am glad you managed to interpret what I suggested around the graphics - with full heights it looks better than I had expected with overlapping tiles. I would hope that these cliffs being created for maps, while they might not be to everyones taste's could potentially be available as a map generation option with the new GUI (prissi?).

I am seeing some errors which might be interrelated (in my code) which I'll look into:
a debug assertion indicating that textures are being created from different sized images is failing so it's likely somewhere a pak160 ground image is being mixed with a pak128 image
water animations aren't displaying entirely correctly as the they seem to stop at 128 pixels down the image

Vladki

Those cliffs on snowy mountains look good - like avalanche protecions

makie

Quote from: Vladki on July 17, 2020, 11:48:31 AM
Those cliffs on snowy mountains look good - like avalanche protecions
Unfortunately there is only one graphic for "slopes"
If it were possible, to define different graphics for seasons and climatics, then you could create better fitting rock faces that are not so eye-catching.

Ranran

Quote from: makie on July 17, 2020, 01:30:37 PMUnfortunately there is only one graphic for "slopes"
If it were possible, to define different graphics for seasons and climatics, then you could create better fitting rock faces that are not so eye-catching.
For example, pak.nippon has only concrete slopes. If there are different graphics such as natural cliffs and artificial ones, the range of expression will be rich.

Vladki

Quote from: Ranran on July 17, 2020, 02:04:25 PMFor example, pak.nippon has only concrete slopes. If there are different graphics such as natural cliffs and artificial ones, the range of expression will be rich.
I think there is. I think in pak128 thera are two types of cliffs - artificial is shown if there is a way or building built on top of it, and natural if the tile above is empty

kierongreen

Indeed pak128 (and pak64, pak128.Britain and probably other) have both artificial and natural slopes/fences.

It would be relatively easy to code different slopes for different climates and summer/winter, although some thought might have to be put into the logic for this especially with climates not dependent on heights - would the cliff have the same climate for the whole height or would it vary (and if so should it be based on the bottom or top of the cliff). Summer/winter would need transition images in a similar way that slopes do. My own opinion is that cliffs rarely have much if any snow so am not sure if there'd be much difference graphically, but artists might have other views.

With this patch as cliff images are now calculated at draw time there's even a few unused bits that could be used for some exotic purpose relating to cliffs (e.g. vertical entrance to a tunnel or something equally new). Ideally it would be something that added to the gameplay though!

Ranran

Quote from: Vladki on July 17, 2020, 02:29:48 PMI think there is. I think in pak128 thera are two types of cliffs - artificial is shown if there is a way or building built on top of it, and natural if the tile above is empty
That is the difference between "slope" and "basement". The slope forces the pakset to choose whether it's all artificial or natural.

makie

Quote from: kierongreen on July 17, 2020, 03:23:21 PMalthough some thought might have to be put into the logic for this especially with climates not dependent on height
Each tile has a climates, isn't it?
Take the climates from the tile behind, as the for the "ClimateTexture", or from the tile that belong to the slope. I don't think it is critical.

I think between Summer/winter there would no need for transition. because there is no big difference and a break or line at the bottom or top is intended.
The only problem, if there are two of them side by side, and one is summer and the other is winter.

For rocky and arctic, i think of  rock faces with more or less snow.
For mediterran i think of artificial build stonewall as for terrace fields

Leartin

Quote from: kierongreen on July 17, 2020, 03:23:21 PM
It would be relatively easy to code different slopes for different climates and summer/winter, although some thought might have to be put into the logic for this especially with climates not dependent on heights - would the cliff have the same climate for the whole height or would it vary (and if so should it be based on the bottom or top of the cliff).
Climate variations for the slopes are probably most useful not for the body of the slope, but for the top and bottom edges. Naturally, the top edge should fit the climate on the tile behind, the bottom edge meanwhile wants to fit the tile in front.
This would allow us to have a nice transistion at the edges, see attached graphic for a quick mockup.

Quote from: kierongreen on July 17, 2020, 03:23:21 PMSummer/winter would need transition images in a similar way that slopes do.
Seasons don't need them any more then climates do, especially considering that winter is just the arctic climate. They would be nice, but we don't have them eg. for ways either - grounds are a special exception.

makie

Quote from: Leartin on July 17, 2020, 06:09:32 PMSeasons don't need them any more then climates do, especially considering that winter is just the arctic climate. They would be nice, but we don't have them eg. for ways either - grounds are a special exception.
The winter snowline can go down until desert depending on the setting.
For summer the colors of the slope for temperate may be green and brown.
For winter there are better gray and white and over all brighter.
Ok arctic is only winter, but rocky change. Maybe winter with snow and winter without snow.

Leartin

Quote from: makie on July 17, 2020, 06:42:09 PM
The winter snowline can go down until desert depending on the setting.
You can have desert climate next to arctic climate as well. The snowline makes no difference in that regard. If you have no transistion from desert climate to arctic climate in the slope, then you don't need a transistion from a tile above winter snowline to a tile below winter snowline either.

Quote from: makie on July 17, 2020, 06:42:09 PM
For summer the colors of the slope for temperate may be green and brown.
If the ground itself does not change through the seasons, is there really a need for slopes to change? If you ask me what would be more affected by seasonal changes - a dead rock face or a vivid meadow - I'd not pick the rock. I'm not saying I don't want seasons, I'm saying that it's silly for slopes to get seasons (beside snowy), in a game where other objects that could need them more don't have them. (not just the ground, but also wayobjects, signals, ... )

freddyhayward

I believe I have found a three anomalies in the original code, one of which you may have inadvertently fixed in the triple heights patch. These are the (I think) missing 'doubles' flag for slopes 33, 34 and 80 in the original code. Of their counterparts in the triple heights patch, 72 (33) and 73 (34) are still missing this flag, while 170 (80) has been fixed. Can you confirm this or have I missed something?

prissi

Slope 80 is only for the tool bar parameter and cannot occur in real games. So there it does not matter. The other were missing indeed, thank you.

freddyhayward

Quote from: prissi on August 03, 2020, 03:31:43 AMSlope 80 is only for the tool bar parameter and cannot occur in real games. So there it does not matter. The other were missing indeed, thank you.
On slope 80, while it doesn't matter, isn't it still better to be internally correct than incorrect?

prissi



makie

Incorporated Patches?  ::-\

No, not Incorporated ::(

prissi

Sorry, I was sure, I move the climate patch.