On further modifications of the terrain system

[SkeletonCrew]

Does porting mean that existing terrains get new names, since that would break compatibility.

Yes. Otherwise we could only use the features of the layer system for new terrain. Which would make it quite useless as we couldn't cleanly generalize the terrain in base/overlay. And the WML would become more complex instead of simpler.

I asked about compatibility before and got no answer that it would break it... Otherwise I wouldn't have the current version being shipped in 1.3.1. I'm not really in the mood to convert mainline again, once was enough... is anybody volunteering to convert mainline?

I made a rough port of the terrain files, and apart from the bugs you mentioned it works extremely well. I made villages, forests and bridges overlays and it really makes the WML much simpler (especially the TERRAIN_ADJECENT lines).

Could you post the files or PM them to me, I'm interested to see how it looks.

For now I'll first look at the speed problem, the layered version is indeed slower on larger maps, not that the previous version was fast...

[mog]

I asked about compatibility before and got no answer that it would break it... Otherwise I wouldn't have the current version being shipped in 1.3.1. I'm not really in the mood to convert mainline again, once was enough... is anybody volunteering to convert mainline?

Well, all incompatible changes would be WML only, so committing the code to 1.3.1 is not that bad.
I might do the conversion once the terrain.cfg is finalized.

Could you post the files or PM them to me, I'm interested to see how it looks.

For now I'll first look at the speed problem, the layered version is indeed slower on larger maps, not that the previous version was fast...

http://yavin.mogsoft.de/~mog/wesnoth/la ... ain.tar.gz
Some strings are placeholders (e.g. farmland), some could maybe be more generalized (e.g. desert rubble). But it works well.

The speed difference is very noticable when using the editor (Nice work with the terrain categories btw. ).

[mog]

I did some profiling and managed to cut the time for building the map in roughly a half. It's still far from what I would call snappy, but it's usable again. Unfortunately I fixed all the low hanging fruits, so getting further speedups will be more difficult (at least without more involved changes).

And there seem to be some portability problems. Sapient committed code to fix VC++6 which causes compilation with gcc to fail .

[SkeletonCrew]

Thanks for looking at it, I didn't have that much time yesterday The 64 bit is problematic in some compilers.
64 bit was the easiest change so I wanted to try that first and it would benefit those who have a 64 bit system. I'll change it to 2 32 bit values and test with that.
I think I'll revert my layer patch and test more with 2 32 bit values. I committed early since I wanted to have it tested with different compilers, to see whether it gives problems.
Your speedup patch won't be reverted of course

The terrain-graphics.cfg looks much nicer indeed

[SkeletonCrew]

I'm busy with the 2 x 32 bit and with -O0 compilation I've the following results for opening a map 200 x 200 tiles of grass
1 layer : 30 seconds
2 layers 64 bit : 5 minutes
2 layers 2 x 32 bit : 3 minutes
so still pretty slow, I want to look at further optimizations however I see the speed at -02 more important since that's the default compilation switch and it allows the compiler to do some more magic.

[torangan]

Testing at -O0 is useless. GCC is known to produce very bad code at -O0 while other compilers do at least some optimizations even when not asked.

[SkeletonCrew]

Testing at -O0 is useless. GCC is known to produce very bad code at -O0 while other compilers do at least some optimizations even when not asked.

I know it's quite worthless but that is how I run wesnoth most of the time, to make it easier to debug. My computer is too slow to quickly recompile at -O2 since the changes in terrain_translation.hpp force a lot of stuff to recompile. I did a short test at -O2 after the previous post and 2 layers with 2 x32 bit is now less than 1 minute.
I only use -02 when I start profiling since otherwise I might run into false bottlenecks.

[SkeletonCrew]

I just added the layer support again, the speed is now 40 seconds instead of 3 minutes in the previous test so only a loss of 10 seconds on a 200 x 200 map and no optimization.

I noticed that the transitions of the keeps have glitches, but also with a version of Wesnoth without the layer support... The disable_transition doesn't seem to do what it's supposed to do

The toprow glitches with this version are the same as before.

[mog]

It doesn't work correctly for me. It seems that it doesn't match any base terrains when the terrain has a layer (Try forests/villages with my t-g.cfg). The overlays are displayed correctly.

[SkeletonCrew]

It doesn't work correctly for me. It seems that it doesn't match any base terrains when the terrain has a layer (Try forests/villages with my t-g.cfg). The overlays are displayed correctly.

I didn't test this version with your t-g.cfg, I just had a closer look and there seem to be problems in your .cfg. Attached the changes I made based on your version.

The problems I encountered
Gg only matches the terrain Gg so changed to Gg^* and move this part to the back, if that is is not done the forest would have about 5% change to have a base terrain. The same for Aa now changed to Aa^*. After these changes the forest and snow forest show properly. I haven't fixed the rest of them but it seems the same case there as well.

Btw it seems the top row glitch is back I'm working on that.

[mog]

The problems I encountered
Gg only matches the terrain Gg so changed to Gg^* and move this part to the back, if that is is not done the forest would have about 5% change to have a base terrain. The same for Aa now changed to Aa^*. After these changes the forest and snow forest show properly. I haven't fixed the rest of them but it seems the same case there as well.

Here you wrote:

Code: Select all

A*       matches Abcd but also Abcd^Abcd 
A*^*     matches Abcd but also Abcd^Abcd

That was also the way it worked in your first version. I would prefer it to stay that way, as the majority of the rules is to match base terrain independently from the overlays. Adding ^* to lots of rules would mean adding a lot of visual clutter to the WML.

For matching a base terrain without any overlays we still have "Abcde^".

[SkeletonCrew]

I tested it and it matches as posted before. terrain_graphics.cpp contains a commented out debug program, feel free to test with that program.

Here some code from your cfg

Code: Select all

{TERRAIN_BASE_PROB  Gg^               flat/grass-rocks1         2}
{TERRAIN_BASE_PROB  Gg                flat/grass-r1             10}
{TERRAIN_BASE_PROB  Ggf               flat/grass-flowers1       20}

None of these lines has a wildcard so it should only do an exact match.
The reason for using Gg^* instead of Gg* is that Gg* would also match Ggf.
With the Aa it will work with both Aa* and Aa^* the only problem would be if somebody adds a terrain like Aac it would also be matched.
The (untested) solution for this case is either add the ^ everywhere or change the order eg

* do terrain rules for Gg
* do terrain rules for Ggf
* do base terrain rules for Gg*

If the 64 bit version did work with the posted t-g.cfg it would mean that there were bugs in that version.

IMHO things work according to the posted matching rules, but since it's still a development version we can still change the rules of how things should work.

[Eleazar]

Btw it seems the top row glitch is back I'm working on that.

I'm leaning towards the abolition of fake hexes, and transitioning to void with a new custom transition— a more abrupt version of shroud. It would be treated like a terrain, so the exact layering could be adjusted, some "tall" graphics would overlap it.

But i don't have time to fake an example yet.

[mog]

The reason for using Gg^* instead of Gg* is that Gg* would also match Ggf.
With the Aa it will work with both Aa* and Aa^* the only problem would be if somebody adds a terrain like Aac it would also be matched.

...

IMHO things work according to the posted matching rules, but since it's still a development version we can still change the rules of how things should work.

In this case I misunderstood the rules you posted. Mainly because I thought that wildcards in the base layer would have no effect on the second layer - which I still think would be sensible.

My main problem with the current rules is that you need to add wildcards for the second layer to most matching strings.

So I suggest making "Abcd" equivalent with "Abcd^*". The (much rarer) case of matching only base terrain without any overlay can still be achieved with "Abcde^"

[SkeletonCrew]

Btw it seems the top row glitch is back I'm working on that.

I'm leaning towards the abolition of fake hexes, and transitioning to void with a new custom transition— a more abrupt version of shroud. It would be treated like a terrain, so the exact layering could be adjusted, some "tall" graphics would overlap it.

But i don't have time to fake an example yet.

It would be trivial to change the engine to return a special type for a terrain offmap. Maybe introduce a special letter for that eg _off so it can have its own matching rules. I'm only not sure whether that would fix the problem, I haven't found the cause of the glitch yet