r5830 new landscape (binary and source versions)

[isidoro]

After some minor problems, I've been able to check the patch and I like it very much.  But in order for it not to be only a change of appearance, I would include it in game mechanics...  For instance, a new rule (maybe pak dependent) that states that rail track or high-speed roads cannot be built on 2x slopes, but roads can...  A sufficiently well thought map would force the player to wisely use tunnels...

That property could be enforced simply: if the images for 2x tiles are not present in the pak, the way cannot be built in such tiles.

[kierongreen]

This is already in the patch. If a way has 4 slope images it can only be built on shallow slopes, if it has 8 it can be built on shallow and steep slopes.

As to whether this can be used in paks that's another question. pak128.Britain has existing slopes as the steeper of the two slope gradients supported, and I think this is also planned for pak128. This means that you must be able to build ways on the steeper slope to allow existing games to be converted (otherwise all rail slopes would disappear for example). pak64 doesn't have this problem as existing slopes will become the shallower of the two slope gradients supported - thus it doesn't even need any new way graphics at all.

[sdog]

This is already in the patch. If a way has 4 slope images it can only be built on shallow slopes, if it has 8 it can be built on shallow and steep slopes.

As to whether this can be used in paks that's another question. pak128.Britain has existing slopes as the steeper of the two slope gradients supported, and I think this is also planned for pak128. This means that you must be able to build ways on the steeper slope to allow existing games to be converted (otherwise all rail slopes would disappear for example). pak64 doesn't have this problem as existing slopes will become the shallower of the two slope gradients supported - thus it doesn't even need any new way graphics at all.

Thus at the beginning players just can't use the shallow slopes in pak128 until someone draws those? At this point they can just decide to take out the steep slopes. Seems like a perfect solution for transition.

[kierongreen]

Shallow slopes must always be present, only steeper slopes are optional.

[kierongreen]

prissi - with that lightmap new images will be needed for ways as the shallow slopes are half existing pak64 ones.

[Ters]

I seem to remember someone writing that bridges only could be built from the steepest slopes. Is that the case? If bridges can be built from both shallow and steep slopes, several new images are needed for the ends, such as up from a shallow slope to match steep slope height at other end.

[kierongreen]

Bridges can be built from both types of slope, I've not coded there to be different graphics yet as it wasn't a real priority.

[kierongreen]

Nearly there for landscape, ways will take a while longer though...

[prissi]

With those textures, sand will need more yellow ...

[kierongreen]

The lightmaps you provided do seem a bit dimmer than the previous ones used - I could brighten them, or alternatively as you suggest use a more yellow texture for sand. I don't want to play around too much with the style of graphics as I wouldn't want to interfere with the pak64 style.

[Markohs]

 It's completely impossible to make this patch able to load paks not updated yet to show double heights? That whould allow to incorporate it to trunk asap. I applied your patch and it works great, but now I can't load any other pak than pak128.britain with your modifications.

I tested pak128, pak96.comic and pak32, quite recent versions and all failedd to start, with a segfault, when they tried to generate images, it crashed here

Code Select Expand



case hang_t::suedwest*2:
all_rotations_slope[slope] = transition_slope_texture->get_bild_ptr(6)->copy_rotate( 180 );
all_rotations_beach[slope] = transition_water_texture->get_bild_ptr(6)->copy_rotate( 180 );



Can't we catch this error more gently and not segfaulting, marking it as not available or something.

If it can load older paks, I'd personally commit this now to trunk and let it go to next release so our users can use it already. It also easens development.

But that's only my opinion. And my excuses if you already discussed iover this, I missed that discussion.

[kierongreen]

Nothing is impossible, but having duplicate code for single and double heights active in the same binary is asking for trouble. Saved games would have to be incompatible between the two height types and it all just gets messy. Even having the conversion factor 1 and 2 started to make things a bit messy (and looking at the lightmaps prissi provided for pak64 I'm not sure was necessary but anyway...).

Adjusted brightness and contrast of lightmap - this any better?

[kierongreen]

Regarding segfaults - it's trying to rotate an image which doesn't exist. It's possible to have a more graceful error but it still won't load.

Urgh, I noticed those lightmaps are shaded from east rather than south, something else to fix...

[Markohs]

 As you wish, but waiting for paks to be updated for this I'm afraid it will take months or even a year for this patch to be incorporated then.

You know the code ofc, but isn't as simple as detecting the lack of 2xheight images and activate a flag that  forbids any modification on the map that causes 2xheight difference on any tile of the map?

[kierongreen]

Flags slow things down. Also at present single height code uses 16 tile images, double height 81. This means different image offsets and so on. For a single height pak to load you'd have to translate all these offsets so it appeared to be a double height pak just with missing images (which hopefully would never be used else -> crash, and check to stop crash means slow down in performance).

As for it taking years, it's been one already, I've waited years before to get things into trunk. The patch is there if anyone wants to try and hack it to work with existing paks. It should be noted that when climates were first introduced a similar incompatibility happened. Generally as long as pak64 and pak128 load it's good enough for a release candidate.

[Markohs]

Flags slow things down. Also at present single height code uses 16 tile images, double height 81. This means different image offsets and so on. For a single height pak to load you'd have to translate all these offsets so it appeared to be a double height pak just with missing images (which hopefully would never be used else -> crash, and check to stop crash means slow down in performance).

Oh, didn't knew it changes offsets, then I understand the bug you mentioned on world borders, must be related to that. The fix will have to have #ifdefined DOUBLE_GROUNDS #else then.


If offsets have changed, I understand both algorithms shoudn't coexist in the game, you are right.


Anyway avoiding SEGFAULTS on lightmap should be done imho, and crash in a proper way (telling the user this pak is unable to be loaded). After all this calculation is done a few times in the game execution, not each frame, performance is not important there.

As for it taking years, it's been one already, I've waited years before to get things into trunk. The patch is there if anyone wants to try and hack it to work with existing paks. It should be noted that when climates were first introduced a similar incompatibility happened. Generally as long as pak64 and pak128 load it's good enough for a release candidate.

I want it incorporated so I don't have to think about how to integrate my code with it anymore, so we can all just work on other aspects of the game. So bugs on your patch become bugs of the game.


If it was for me I'd personally incorporate it in a week and break the back compability with not updated paks. It's a very nice patch, our players should be able to use it soon.


But it's your patch, won't insist more on this.

[kierongreen]

Believe me it's just as frustrating keeping a patch up to date with changes going on in trunk!

To my mind plan of action should be:
Release a stable version of simutrans without double heights
Incorporate patch into trunk, compile release candidate for testing - at this stage if anyone wants to keep using old paks they can either keep using the stable version or compile their own version from source with DOUBLE_GROUNDS unset.
Once pak64 and pak128 are fully compatible, and new code has been tested release a new stable.
Some months down the line DOUBLE_GROUNDS #ifs can be removed along with old single height code to avoid having to maintain two lots of code.

[Sarlock]

Wanted to test some stuff tonight (and see what all will be involved to convert pak128 over), did a clean installation of Simutrans in to a different folder and put the newest patch files from April 3 over the clean install.

Got an error when running sim.exe:

Code Select Expand

FATAL ERROR: loadsave_t::rdwr_str() - expected "<i8>", got "<i3>"
Aborting program execution ...

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: sim.exe
  Application Version: 0.113.3.0
  Application Timestamp: 515b5bf7
  Fault Module Name: sim.exe
  Fault Module Version: 0.113.3.0
  Fault Module Timestamp: 515b5bf7
  Exception Code: 40000015
  Exception Offset: 001c5c4a
  OS Version: 6.1.7601.2.1.0.256.48


I tried a few different approaches (put sim.exe in my trunk and put the pak file changes over my pak128.Britain install) but still got the same error result.  I removed the demo.sve but it didn't matter.

When I run the regular simutrans.exe in the same folder it uses the modified lightmaps for pak128.Britain and it looks all funky, so I know that part is working fine.

Not sure if I am missing a step or if it just doesn't like me.    Let me know if you need further details.

[IgorEliezer]

It's completely impossible to make this patch able to load paks not updated yet to show double heights? That whould allow to incorporate it to trunk asap. I applied your patch and it works great, but now I can't load any other pak than pak128.britain with your modifications.

My 2¢: we already have paksets that are 1 or 2 years outdated. It's impossible to get the major paksets ready for the new system in a few months. Is it possible to use placeholder graphics? In some games, when the engine finds a missing texture or graphic, the engine  "paints" the objects or walls with a plain monochrome texture instead of crashing -- at least it "invites" people to complete the set.

Unless there are too many required graphics that it's not worth doing.

[Markohs]

sharlock it's the settings.xml that's incompatible too. on your simutrans user dir, i personally renamed it to test this so the game created a new one.

[Dwachs]

@Sarlock: please delete settings.xml. Kieron's patch has a small 'bug' concerning reading this configuration file.

@Kierom: Imho not having backwards compatibility (ie crashing with old paksets) is a show stopper. We should provide a work around programatically. By either
(1) distributing a set of lightmaps for all commonly used pak sizes
(2) computing not available lightmaps on the fly (stretching/scaling)
(3) disable double slopes if these images are missing (just no double slopes).

As to disabling double slopes: If not all images for light maps are there then treat the pakset as if the double height images are missing (then bridge and tunnel building works the old way). Terraforming is then restricted to single-height slopes. World generation has to obey this limitation as well. Imho no performance critic parts are concerned, only less ways of modifying terrain are supported. I would volunteer to work on this.

If the patch will be committed it should be done without any of those '#ifdef DOUBLEHEIGHTS'. After the patch has been submitted there is no point in supporting two ways of compiling the program.

[Markohs]

(2) Seems reasonable, just supply a 128 or 256 pixels generic version and scale it up down/up if the pak we are loading doesn't supply one. That should do the trick.

This also makes creating new paks easier, because we have default lightmaps, the pak creator has the option to everride them if he wants to.

I offer my help whatever you need it too, ofc.

[kierongreen]

The game would be pretty much unplayable with placeholder graphics.  Every tile on the landscape would look incorrect. However to just get a pak to load you will be able to copy the pak64 for 64 sized paks or pak128.Britain lightmap for 128 sized paks. That's the vast majority of paks covered - I know there are 32, 96 and 192 sized ones but how much are these actually used?

[Markohs]

What do you think of suppling a default lighmap of let's say 256 or 32 pixels and scale to the needed one if the pak we load doesn't supply one?

All this calculations are just done on map creation/load, this shoudn't affect performance of the game.

[IgorEliezer]

If there's no proper graphics for double-height, then:
- For a normal user/by default: disable the double-height, since it's unplayable.
- For a pakset maker: enable double-height and load placeholder graphics, so that the maker can produce and test the new graphics.

[prissi]

I would agree to what Dwachs said. Probably just a pak option (like the diagonal_length=728) called "enable_doubleheight=1" Default would be of course off. Thus only paks enable this would do double height.

The only performance critical stuff is making very height mountains, due to the recurse calling sequence. It does not has to be recursive anyway, one could test a pyramide immediately. All other stuff should not matter I think so too.

[kierongreen]

Lightmaps scaling to paksize isn't guaranteed to work reliably. One reason I choose to use lightmaps to start with rather than just calculations was that I found it impossible to get the tiles to align correctly any other way. I'm trying to get pak64 working at moment if I have time I might try getting other paks to work.

Having single and double heights supported simultaneously is in my opinion just going to be messy both in terms of code and people using the program. At the moment there is a basic level of compatibility between all paksets - that would be broken if some were double height and some single.

[sdog]

If there's no proper graphics for double-height, then:
- For a normal user/by default: disable the double-height, since it's unplayable.
- For a pakset maker: enable double-height and load placeholder graphics, so that the maker can produce and test the new graphics.

A set of default light maps seems to be sensible. Even when ugly it would work at least. With the setting where the height of today is normal height and double height is twice that way graphics would not be required to play. Building in restrictions seems seems superfluous.

There are only a few sizes required: 32 64 96 128 192. Two are already . For two more there are paks that are actively developed (comics). Including five sets of ptemade default light maps as a fallback?

This could even be done with the pak installer.

[kierongreen]

Yes, I thought that normal and double the height of way graphics was how prissi wanted pak64 to go, but the lightmap supplied is half and normal height. As such at present there are no heightmaps which would allow ways to be used without modification at present.

Anyway, flipped the lightmaps (more involved than I thought...). Problem is that the original lightmap had a light source actually from East North East, therefore flipping it gives a light source of south south west which doesn't quite match shadows which assume a light source ever slightly to east of south. See screenshot:

[prissi]

The lightmaps were done for OpenTTD, so half height as well as wrong shadow is likely from this. However, there is a graphics which spans the entire 64 pixel in height. THat could not be halfheight, of?

The installer is not used on unix. But for the paks on SF a new release could be easily made, by just adding the zip. However, then you will have lots impassable terrain, unlike older versions.

[kierongreen]

Well, the lightmap has a full set of halfheight tiles, however it also has some of the tiles necessary for double heights. Although 81 images are needed for 3x3x3x3 corner combinations infact 17 of these are duplicates, meaning it's actually only 64 images needed in game. This lightmap has an additional 21 images which are used to cope with up to 5 heights on diagonal tiles. This makes sense if they were designed for TTD - this had the possibility for 3 heights on diagonal tiles even when the rest of the tiles were single height.

Anyway, another comment regarding compatibility. This patch adds 3 main features to simutrans - climates, water height and double heights. The double height sections are all within #if DOUBLE_GROUNDS just as used to be the case. Therefore if this patch is applied, but DOUBLE_GROUNDS is left undefined then the only change necessary for existing paks should be to the texture transition images - water heights and climates should appear in game but ground height behaviour will be unchanged. This worked some time ago I'm not sure whether it still functions correctly.

[Bear789]

This is very exciting!

Not related to development, but I have a question: I'm making a greyscale map for my future game. Since I want to do it for Pak Britain, which I understand is duoble height ready, and since this patch seems close to completion, I wonder if the greyscale done with the old parameters will still wor or what changes should I do to it to take full advantages of the new landscape.

[kierongreen]

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.

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.

[jamespetts]

Is there any way, I wonder, of allowing for the full/double height slopes in a map generated from a height map?

[Carl]

I was about to ask something similar -- that is, will "steep" areas in heightmaps automatically generate double-height slopes? (Steep gradients are, as you know one of the things that the current heightmap system handles poorly).