News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

r5830 new landscape (binary and source versions)

Started by kierongreen, July 19, 2012, 06:57:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Markohs

Quote from: kierongreen on April 10, 2013, 10:27:20 AM
Another quick note - I've now got all the #if DOUBLE_GROUNDS macros working again, and now with DOUBLE_GROUNDS left undefined existing patches work with the patch. I'll attach a new version here once I've fixed the bug with squares around map borders.

I was just going to do that now, the function to fix is grund_t::display_border

Before DOUBLE_GROUNDS the x,y was assumed to be 3*height step upwards the center of the current tile to draw (iirc). With your patch that offset has changed. I can try fixing it with your patch (was applying it again now) or you can fix yourself, as you wish. :)

Markohs

#141
I've applied your patch and well, the fixed function, that fixes all glitches in both old version and DOUBLE_GROUNDS is this one, can you test it? I'll upload to trunk if it's ok in your oppinion.


void grund_t::display_border(const sint16 xpos, const sint16 ypos, const sint16 raster_tile_width, const uint8 border_direction)
{
   if(!ist_karten_boden()){
      return;
   }

#ifndef DOUBLE_GROUNDS
   const sint16 y_imp_offset = 0;
#else
   const sint16 y_imp_offset = tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);
#endif


   // We'll paint 8*height from the center of the tile upwards, size width/2 on top borders (west and north)

   if( border_direction & ribi_t::west ) {
      const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
      const int corner_height = tile_raster_scale_y( corner1(slope)*TILE_HEIGHT_STEP,raster_tile_width);

      const int y_origin = ypos + y_imp_offset - corner_height - tile_raster_scale_y( TILE_HEIGHT_STEP*5, raster_tile_width);

      display_fillbox_wh_clip(xpos, y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);

      set_flag(dirty);
   }

   if( border_direction & ribi_t::nord ) {

      const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
      const int corner_height = tile_raster_scale_y( corner3(slope)*TILE_HEIGHT_STEP,raster_tile_width);

      const int y_origin = ypos + y_imp_offset - corner_height  - tile_raster_scale_y( TILE_HEIGHT_STEP*5, raster_tile_width);

      display_fillbox_wh_clip(xpos + (raster_tile_width>>1), y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);

      set_flag(dirty);
   }

   // We'll paint 8*height from the center of the tile downwards, size width/2 on bottom borders (south and east)
   if( border_direction & ribi_t::ost ) {
      const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
      const int corner_height = tile_raster_scale_y( corner3(slope)*TILE_HEIGHT_STEP,raster_tile_width);

      const int y_origin = ypos + y_imp_offset - corner_height  + tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);

      display_fillbox_wh_clip(xpos + (raster_tile_width>>1), y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);

      set_flag(dirty);

   }

   if( border_direction & ribi_t::sued ) {
      const int height_to_paint = tile_raster_scale_y( TILE_HEIGHT_STEP*8, raster_tile_width);
      const int corner_height = tile_raster_scale_y( corner1(slope)*TILE_HEIGHT_STEP,raster_tile_width);

      const int y_origin = ypos + y_imp_offset - corner_height  + tile_raster_scale_y( TILE_HEIGHT_STEP*3, raster_tile_width);

      display_fillbox_wh_clip(xpos, y_origin, raster_tile_width>>1, height_to_paint, umgebung_t::background_color, false);

      set_flag(dirty);
   }
}

kierongreen

If you are using a simutrans executable with this patch applied heightmaps automatically use steep slopes yes.

Also can confirm that your fix works Markohs :)

IgorEliezer

Out of curiosity: in this new landscape system, will the climates be per-tile/region based or remain depending on the height levels?

kierongreen

On map generation (and when you raise or lower land) they are calculated depending on height level. However you can change the climate of any tile or region afterwards with the climate tools.

Markohs


IgorEliezer

#146
Quote from: kierongreen on April 10, 2013, 03:41:26 PMHowever you can change the climate of any tile or region afterwards with the climate tools.
This is a thing, a good one.

I don't know the future plans as I sincerely don't want to push anything, but I see this as the 1st first step for a climate generation that is not so constrained to heights and looks more natural or simply random.

To see how this could be possible (I'd hate to look greedy on feature request), I made a search to find something about randomly generated regions for game environments: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/, the article looks interesting and the source code is available on github.

EDIT:

A demo is available for those who want to see how it works: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/mapgen2.swf

TurfIt


IgorEliezer

Hahah... how could I forget that!

Can I bandwagon? A new geography for Simutrans: terrain, climate, towns, factories and stuff

* IgorEliezer runs for the hills.

EDIT:

Hey, Fabio is reading this topic. I believe we will need a bigger bandwagon. :>

Fabio


kierongreen

QuoteI don't know the future plans as I sincerely don't want to push anything, but I see this as the 1st first step for a climate generation that is not so constrained to heights and looks more natural or simply random.
One step at a time! Beaches are already dependent on more than just height, being based on the number of neighbouring water and land tiles as well. Having other climate features would not be that difficult :)

jamespetts

Igor - for what height of hill are you running?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

IgorEliezer

By chance, did you mean the mountain height I like to play on? I like to use the max value, 320, and max value for roughness too, 7.

kierongreen

Max value for roughness is 10 with double heights by the way :)

Attached is the source for patch to 6448 trunk. pak64doubleheight-src.zip contains files to get the pak64 landscape working (pavement half height images are from pak64.Unity).

For pak128.Britain only change is to TextureGrounds.dat from the last release as only 5 images are needed now for this - the new ShoreTrans section is:
# these images define the beach transition
Obj=ground
Name=ShoreTrans
Image[0][0]=images/texture-shore.0.0
Image[1][0]=images/texture-shore.0.1
Image[2][0]=images/texture-shore.0.2
Image[3][0]=images/texture-shore.0.3
Image[4][0]=images/texture-shore.2.3

(the new pak128 branch will have to have this change applied)

I'm away for the next few days will make a proper release when I get back.

Oh by the way, Markohs - the patch you made to border tiles uses spaces rather than tabs to indent lines which doesn't match the style used in the rest of the code

Markohs

Oh, ****, I found strange the diff showed so many different lines, but coudn't see what was wrong. That's what happens when you copypaste from forum.

Thx, will fix on next update. :)

Dwachs

Kieron, please REMOVE / REVERT this piece of the patch

--- dataobj/umgebung.cc (revision 6448)
+++ dataobj/umgebung.cc (working copy)
@@ -289,7 +290,7 @@
file->rdwr_bool( window_buttons_right );
file->rdwr_bool( window_frame_active );

- if(  file->get_version()<=112000  ) {
+ if(  file->get_version()<=113000  ) {
// set by command-line, it does not make sense to save it.
uint8 v = verbose_debug;
file->rdwr_byte( v );

This if-clause has no effect on your patch, but is responsible for the crash Sarlock reported above. I guess you did some global search & replace of file-versions, and this query on version was replaced unintended.
Parsley, sage, rosemary, and maggikraut.

kierongreen


The Hood

Quote from: Markohs on April 10, 2013, 04:09:00 PM
Commited @6446 then :)

Is half height now in trunk then? Should I start enabling all the half height bits in the pak128.Britain code?

Fabio

You could branch it the way we did in vanilla Pak128 ;)

kierongreen

Quote from: The Hood on April 13, 2013, 09:56:20 AM
Is half height now in trunk then? Should I start enabling all the half height bits in the pak128.Britain code?
I believe the only code added to trunk was that to fix the border.

The Hood

Quote from: kierongreen on April 13, 2013, 10:04:37 AM
I believe the only code added to trunk was that to fix the border.

Thanks - nothing happening for now then.

Quote from: Fabio on April 13, 2013, 10:00:00 AM
You could branch it the way we did in vanilla Pak128 ;)

Kieron essentially has a branch for that purpose that he tests with. I'm hoping we can just copy those files over when we are ready to roll...

Bear789

Quote from: kierongreen on April 10, 2013, 10:27:20 AM
Heightmaps work equally well with and without double heights. However the map will appear to be half the height it is at present as each tile height will be half the existing one.

Ok, thanks.
I'll try what happens when this will be included in some nightly.

Sarlock

I've made some new graphics and went to compile them with makeobj but it's asking for DLLs that I don't have... I'm really reluctant to just go out into the internet and start downloading DLL files because of the potential for damage.

libgcc_s_dw2-1.dll was the first one.  I was able to find a copy that I *think* (hope) was safe.

Now it's asking for libstdc++-6.dll.  I can't seem to find a site to grab this that I feel comfortable with.  I imagine that since no one else is having this issue, they already have these DLL files.  If someone can link to a safe copy I'd be very appreciative.  And if there are any other DLL files I require after that one, it would help too :)

Is it intentional to require these DLL to be able to run the program? (pardon my computer programming illiteracy)
Current projects: Pak128 Trees, blender graphics

TurfIt

#163
Where's your makeobj.exe from?
Asking for those .dlls indicates someone compiled it with MinGW but didn't statically link the standard libraries...

Edit:
Brainfart.... I assume you got it from kierongreens windows binary posting. For proper compatibility, you really to obtain the .DLLs from him. Any others might be from a different MinGW version and hence have issues...

@kierongreen - setting LDFLAGS = -static-libgcc -static-libstdc++
does the static linking...

kierongreen

#164
Will have a look at that when get home. My windows builds are made with mingw running inside wine and tested with wine also so don't always pick up on these things...

Static linking seems to be enabled in simutrans but not makeobj for compiling under mingw - this is something that could be fixed in trunk.

Sarlock

Sounds good, I'll await an update regarding this question and continue to do the graphics conversion and test later.  Thanks  :)
Current projects: Pak128 Trees, blender graphics

Dwachs

#166
Kierongreen, can you please post the latest patch file? (Or is the one you posted here is still the current state?)

Edit: I am working on making this patch work with traditional paksets. While I am at it, I will gradually remove the #ifdef DOUBLE_GROUND stuff.
Parsley, sage, rosemary, and maggikraut.

kierongreen

Patch from latest trunk attached.

Regarding getting this to work with existing paksets. I'd really recommend not following this path because of potential errors but key things to think of are:
Will you have a variable in the saved game to store whether it is double height or not - will existing games be converted to double height if possible (this happens automatically at present)?
Will landscape when using existing paksets be converted to double height, but then heights limited to multiples of 2, or will you keep the landscape unconverted?
How will you deal with a double height map being loaded with a single height pakset

Edit
NOTE I've realised this version includes half ready code to have different images for bridges based on heights of slopes at the ends. It doesn't function correctly graphically in game but shouldn't cause any significant problems other than that.

Dwachs

#168
I added a check in grund_besch.cc whether enough slope images are present or not. In the terraforming code I used

const sint8 max_hdiff = grund_besch_t::double_grounds ? 2 : 1;

Internally, it behaves like a double slope map, however slopes are restricted to the old single slopes. For the non-existent double slopes dummy images are generated. The indexes into border and marker images are converted internally.

Does this make sense?

What files did you change in you updated patch? I have updated it too here...

Quote from: kierongreen on May 09, 2013, 06:37:18 PM
Will you have a variable in the saved game to store whether it is double height or not - will existing games be converted to double height if possible (this happens automatically at present)?
Game will be internally double height, slopes are restricted to single height slopes.
Quote
Will landscape when using existing paksets be converted to double height, but then heights limited to multiples of 2, or will you keep the landscape unconverted?
I did not need to touch the loading part. Your implementation works ...
Quote
How will you deal with a double height map being loaded with a single height pakset
Add a fatal-error? do you think this case is realistic? Who will load a savegame, which was saved with a new pakset, with an old pakset?


I would like to throw out all the 'ifdef DOUBLEGROUND' stuff. What do you think?

Edit: I checked the difference between our patches with interdiff: they do differ in different places of the code, so no conflict...
Parsley, sage, rosemary, and maggikraut.

Ters

Quote from: Dwachs on May 09, 2013, 06:57:01 PM
Who will load a savegame, which was saved with a new pakset, with an old pakset?

It will be someone who doesn't understand cryptic error messages. I'm certain of it.

Dwachs

Here is my patch. Imho, we can risk inclusion in trunk.

Quote from: Ters on May 09, 2013, 08:01:35 PM
It will be someone who doesn't understand cryptic error messages. I'm certain of it.
:) I tried: creating game with Kieron's modified pak128.Britain, loading in standard pak128.Britain: slopes are truncated, bridges are broken. It does not make sense to write code to transform such savegames.

Edit: there is some strange behavior of beach transitions for new created maps. If I do terraforming there and restore landscape, the transitions are then corrected.
Parsley, sage, rosemary, and maggikraut.

prissi

#171
Splendid (to quote James). Very good, that makes inclusion much easier.

kierongreen

#172
This behaviour of beach transitions is intended :)

Edit: I think bridges will still be broken (graphically). I'm working on a fix for that though.

Edit2: Dwachs patch above doesn't include my changes to bridges. Therefore there's no fix required.

kierongreen

#173
Dwach's patch updated to 6501. Have improved handling of bridges to prepare for graphics for 1 and 2 height end slopes (not actually implemented these yet though), and to correct hiding of asymmetrical pillars.

While both old and double height paks now work this is not foolproof. Loading an old (single height) saved game with an old (single height) pak crashes simutrans here (whereas loading it with a double height pak converts and runs correctly).

Edit:
Seems like that crash wasn't related to double heights as it also happens on trunk 6501 without patch applied. It's actually related to a missing factory pak (in the old pak128.Britain) and the new non-rectangular factory code. If a pak is missing then besch doesn't exist, therefore no valid building is returned for any of the factory coordinates, therefore trying to return the position of the building gives a segmentation fault.

Ters

Quote from: Dwachs on May 09, 2013, 08:23:55 PM
:) I tried: creating game with Kieron's modified pak128.Britain, loading in standard pak128.Britain: slopes are truncated, bridges are broken. It does not make sense to write code to transform such savegames.

No it doesn't, but an understandable, preferably translated, error message in the GUI is needed for such cases.