On further modifications of the terrain system
Moderator: Forum Moderators
The bridge wml is quite complex, but I will take a look.Eleazar wrote:Yeah, but bridges over different types of water don't interact properly. Somebody with greater WML skills should take a look.
By the way: You used Bwo* and Bss* for deep water and swamp bridges. You probably did this as an analogy to Bww*, but the ww was meant to stand for wooden/water (or water/wooden).
I suggest we use B(Base type)(Bridge type)(Direction) as strings, this makes the wml easier.
So I'd like to change the new bridges to Bow* and Bsw* (They should not yet be used by many people)
Aurë entuluva!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.mog wrote:The bridge wml is quite complex, but I will take a look.Eleazar wrote:Yeah, but bridges over different types of water don't interact properly. Somebody with greater WML skills should take a look.
By the way: You used Bwo* and Bss* for deep water and swamp bridges. You probably did this as an analogy to Bww*, but the ww was meant to stand for wooden/water (or water/wooden).
I suggest we use B(Base type)(Bridge type)(Direction) as strings, this makes the wml easier.
So I'd like to change the new bridges to Bow* and Bsw* (They should not yet be used by many people)
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
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
Looking at the code a bit, it looks like it should not be hard to remove the 4-letter limit. SC correct me if I am wrong, but it looks like this was done for convenience: currently the code just takes the four chars and makes it into a single 4-byte integer. It ought to be possible to instead just keep a vector of strings and have the integer associated with it just be the index in the vector. When a new terrain string is encountered, it just gets pushed onto the back of the vector. This might be slightly slower, but I don't think that it would be a huge performance hit.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?Eleazar wrote:The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.
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
[joke_mode]
4 letters should be enough for everybody
[/joke_mode]
but jokes aside yes it's possible to do that, some items need have a fixed letter (the consts declared in the terrain_translation.cpp) other than that the code shouldn't make assumptions about what the numbers are.
Note that the builder code also does some special tricks it stores the map char read in byte 0 of the u32 and uses the other 3 bytes for the anchor number.
It might be wise to limit to some number so the alignment of the map file is a little bit readable.
Before you start also look at get_mask_ since the change makes the wildcard matching harder and it might slowdown the parsing of terrain-graphics.cfg much.
There's only 1 thing bugging me; I thought about doing it like that before but then I saw a big pitfall, but I can't remember what.
Maybe switching to an u64 might even be easier (and faster) since it keeps the wildcard matching simple. Once the old char support is dropped I want to allow the wildcard at all places where multiple terrains are allowed.
4 letters should be enough for everybody
[/joke_mode]
but jokes aside yes it's possible to do that, some items need have a fixed letter (the consts declared in the terrain_translation.cpp) other than that the code shouldn't make assumptions about what the numbers are.
Note that the builder code also does some special tricks it stores the map char read in byte 0 of the u32 and uses the other 3 bytes for the anchor number.
It might be wise to limit to some number so the alignment of the map file is a little bit readable.
Before you start also look at get_mask_ since the change makes the wildcard matching harder and it might slowdown the parsing of terrain-graphics.cfg much.
There's only 1 thing bugging me; I thought about doing it like that before but then I saw a big pitfall, but I can't remember what.
Maybe switching to an u64 might even be easier (and faster) since it keeps the wildcard matching simple. Once the old char support is dropped I want to allow the wildcard at all places where multiple terrains are allowed.
You are right to some degree. If we added another swamp we could just use any free letter for the respective bridge.torangan wrote:I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?Eleazar wrote:The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.
On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.
But as the new bridges are in svn already, we should leave it as it is. Whoever commits the first stone bridge will have to think of something.
Aurë entuluva!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
The problem where is we're actually putting two terrains on top of each other, and that were trying to make the terrain codes meaningful.torangan wrote:I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?Eleazar wrote:The problem is that a single letter for base type is not sufficient, if the number of watery terrains is expanded at all. A single letter does not allow for another type of swamp, for instance. For bridges 4 letters gets crowded quickly.
These dual-layer terrains (villages, bridges, forests) can reasonably have quite a few types when you multiply the number of top layer variants, with the number of reasonable under-layers.
The most flexible (and probably hardest to implement) is to allow the assignment of both layers separately. The Wooden bridge would default to having shallow water beneath (defined by the terrain.cfg) but the map could specify something else instead: "Bw/+SS," for a wooden bridge over standard swamp.
Yes, this sort of thing could make the columns wider, but so would adding length to the terrain code. On a tangent, the maps might be maximumly human-readable, if the padding between columns was the difference between the longest and shortest code in that map + 2.
This sort of issue isn't unique to the bridges, placing various types of swamps under various swamp villages etc, would cause the same type of problem.mog wrote:On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.
We can cope for a while, since additional kinds of bridges etc, are so-far theoretical.
Last edited by Eleazar on January 30th, 2007, 11:44 pm, edited 1 time in total.
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
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.mog wrote:You are right to some degree. If we added another swamp we could just use any free letter for the respective bridge.torangan wrote: I wonder why this is the case. A single letter in the new systems allows as much options as we had all over so far unless I'm mistaken?
On the other hand we should try to keep the strings somewhat mnemonic so the WML stays comprehensible (well... at least somewhat). So we could add another top-level letter for e.g. stone bridges, but I can't think of a free one that wouldn't be as arbitrary as using Bz* for a bridge on some swamp variation.
But as the new bridges are in svn already, we should leave it as it is. Whoever commits the first stone bridge will have to think of something.
@torangan yes every letter allows as much options at the entire previous system.
So the problem isn't that we've not got enough combinations now, it's that you want to keep them rather readable. Good luck, this will only work if you go for much more then 4 letters like Darth Fool described. This will allow therotically 2^32 combinations which is enough for everyone. The only problem is that the map won't be easy to read anymore because the columns are very wide.
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!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
I agree that we should have these things settled before a release.SkeletonCrew wrote:You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.
However, the bridge designations on the wiki are lousy. (which is probably my fault) If "B" stands for all bridges, the second letter should probably indicate the type of bridge to allow for wild-carding.
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
Good point, I think it's better to have good support for wildcards then readable strings. With a growing number of variants the latter won't be possible for long most likely anyway but easy matching improves the performance.
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!
You're probably right. I wanted to use the second letter for the base terrain so you could use wildcards in the base terrain transitions, but as there will probably be more types of terrain than types of bridges, we should do it your way.Eleazar wrote:I agree that we should have these things settled before a release.SkeletonCrew wrote:You're right that they're in svn but they're not documented here http://www.wesnoth.org/wiki/TerrainLettersWML#Bridges yet. That same page reserved Bsw for the swamp bridge. So I'd say if you prefer Bsw and Bow change it now, since it's very probably unused. Once 1.3.1 is released we shouldn't change it anymore.
However, the bridge designations on the wiki are lousy. (which is probably my fault) If "B" stands for all bridges, the second letter should probably indicate the type of bridge to allow for wild-carding.
@torangan
I know how important wildcard support is. Fortunately internal consistency (which is required for efficient wildcard use) is usually good for readability.
Aurë entuluva!
- Eleazar
- Retired Terrain Art Director
- Posts: 2481
- Joined: July 16th, 2004, 1:47 am
- Location: US Midwest
- Contact:
Wild-card support and human-readability are complimentary not contradictory goals. The consistent naming conventions, required for wildcards support readability.torangan wrote:Good point, I think it's better to have good support for wildcards then readable strings. With a growing number of variants the latter won't be possible for long most likely anyway but easy matching improves the performance.
EDIT: replied the same thing, simultaneously with Mog.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
That is true, but everywhere else that terrain strings are used (terrain filters come to mind) will be a lot more readable. Even with 4 characters the maps are basically too big to be easily human readable.torangan wrote:The only problem is that the map won't be easy to read anymore because the columns are very wide.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
-
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
What length limit are you thinking of 8 characters or infinite? I really fear that the wildcard code gets much slower if it has to process strings instead of a integers. I already suspect the change to an u64 might slow down quite a bit. (A 64 bit processor will have less trouble with it.)
The usage of the t_match structure sped up the matching for the terrain graphics considerably (didn't measure but it was noticeable).
The usage of the t_match structure sped up the matching for the terrain graphics considerably (didn't measure but it was noticeable).