On further modifications of the terrain system
Moderator: Forum Moderators
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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?mog wrote: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.SkeletonCrew wrote:Does porting mean that existing terrains get new names, since that would break compatibility.
Could you post the files or PM them to me, I'm interested to see how it looks.mog wrote: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).
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...
Well, all incompatible changes would be WML only, so committing the code to 1.3.1 is not that bad.SkeletonCrew wrote: 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 might do the conversion once the terrain.cfg is finalized.
http://yavin.mogsoft.de/~mog/wesnoth/la ... ain.tar.gzSkeletonCrew wrote: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...
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. ).
Aurë entuluva!
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 .
And there seem to be some portability problems. Sapient committed code to fix VC++6 which causes compilation with gcc to fail .
Aurë entuluva!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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
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
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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.
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.
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.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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.torangan wrote: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 only use -02 when I start profiling since otherwise I might run into false bottlenecks.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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.
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.
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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.mog wrote: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.
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.
- Attachments
-
- terrain-graphics.cfg
- (1.07 KiB) Downloaded 901 times
Here you wrote:SkeletonCrew wrote: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.
Code: Select all
A* matches Abcd but also Abcd^Abcd
A*^* matches Abcd but also Abcd^Abcd
For matching a base terrain without any overlays we still have "Abcde^".
Aurë entuluva!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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
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.
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}
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
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
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.SkeletonCrew wrote:Btw it seems the top row glitch is back I'm working on that.
But i don't have time to fake an example yet.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
-> What i might be working on
Attempting Lucidity
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.SkeletonCrew wrote: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.
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^"
Aurë entuluva!
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
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 yetEleazar wrote: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.SkeletonCrew wrote:Btw it seems the top row glitch is back I'm working on that.
But i don't have time to fake an example yet.