Small enhancement for terrain system
Moderator: Forum Moderators
Small enhancement for terrain system
Currently, there are two ways to determine the stacking of images: horizontal and vertical.
Normal transitions use the horizontal method (where stacking is determined by a layer number), vertical positioning is used by castles and the chasm/lava/wall transitions where stacking is determined by a x/y coodinate.
Unfortunately the methods can't be combined, so it's not possible to draw one vertical transition always below another. This leads to graphics glitches that can only be fixed by drawing new custom tiles (like wall/chasm or wall/lava/castle transitions).
The linked patch adds the "combined" layering method, which does what the name implies. These images are layered first by layer number and then by x/y position.
I'd like to see this patch in 1.2, it's rather small and preserves behaviour for images that don't use "combined" (Execpt for images with layer=0 which aren't used by us as far as I can see - all our layers are far below 0)
I'll commit it, if there is no opposition.
patch: http://yavin.mogsoft.de/~mog/wesnoth/layers.diff
Normal transitions use the horizontal method (where stacking is determined by a layer number), vertical positioning is used by castles and the chasm/lava/wall transitions where stacking is determined by a x/y coodinate.
Unfortunately the methods can't be combined, so it's not possible to draw one vertical transition always below another. This leads to graphics glitches that can only be fixed by drawing new custom tiles (like wall/chasm or wall/lava/castle transitions).
The linked patch adds the "combined" layering method, which does what the name implies. These images are layered first by layer number and then by x/y position.
I'd like to see this patch in 1.2, it's rather small and preserves behaviour for images that don't use "combined" (Execpt for images with layer=0 which aren't used by us as far as I can see - all our layers are far below 0)
I'll commit it, if there is no opposition.
patch: http://yavin.mogsoft.de/~mog/wesnoth/layers.diff
Aurë entuluva!
hmm
well, I am not convinced if the risk/gain ratio of this patch is good enough for 1.2 at this stage, we are REALLY trying to limit ourselves to critical bug fixes at this poin t (codewise of cours. Art can still go in as you've probably noticed)
I am not opposed to have it commited to trunk though, esp since this is an area of code I don't know well, and you're both a coder and a heavy user of that part. so you probably know what your doing.
however I would advise not commiting this to trunk until 1.2 is out, this way we keep the compatibility of the terrain WML and we can simply copy/paste images and WML from trunk to 1.2 as is.
if we improve the terrain WML we will have to proofread everything to make sure it's worth it...
so I don't think commiting that to 1.2 is a good idea, and for trunk I would advise waiting a little...
well, I am not convinced if the risk/gain ratio of this patch is good enough for 1.2 at this stage, we are REALLY trying to limit ourselves to critical bug fixes at this poin t (codewise of cours. Art can still go in as you've probably noticed)
I am not opposed to have it commited to trunk though, esp since this is an area of code I don't know well, and you're both a coder and a heavy user of that part. so you probably know what your doing.
however I would advise not commiting this to trunk until 1.2 is out, this way we keep the compatibility of the terrain WML and we can simply copy/paste images and WML from trunk to 1.2 as is.
if we improve the terrain WML we will have to proofread everything to make sure it's worth it...
so I don't think commiting that to 1.2 is a good idea, and for trunk I would advise waiting a little...
Fight key loggers: write some perl using vim
-
SkeletonCrew
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
but I'll have a look at the patch tomorrow. I'm inclined to agree with boucman, but we can also put the patch in my branch already.Now that 1.2 is out, I revised my patch a bit:
I removed the "position" attribute completely. If no layer/base values are specified, it will default to layer=0 and base=36,36 (or tilewidth/2 to be precise).
The behaviour is now almost fully compatible with the current version (Exception: horizontally layered images with layer=0 are now in front of vertically layered images with basey < 36 - but this doesn't occur in our wml).
Layering still works as I outlined in my first post, but base values < 0 are now possible (those can also happen by rotation, so this was a bug waiting to happen). Valid values for base(x,y) are between -50000 and 49999. For layer we can keep the current range of -1000-1000 (though +/- 21000 would be possible).
Foreground/Background handling (which btw. seems to be broken for quite some time) is now also compatible to the current version (and doesn't interfere with layering anymore): All images with layer < 0 and images with (layer=0 and base-y < 54) are background, the rest is foreground.
Please comment: http://yavin.mogsoft.de/~mog/wesnoth/layers.diff
I removed the "position" attribute completely. If no layer/base values are specified, it will default to layer=0 and base=36,36 (or tilewidth/2 to be precise).
The behaviour is now almost fully compatible with the current version (Exception: horizontally layered images with layer=0 are now in front of vertically layered images with basey < 36 - but this doesn't occur in our wml).
Layering still works as I outlined in my first post, but base values < 0 are now possible (those can also happen by rotation, so this was a bug waiting to happen). Valid values for base(x,y) are between -50000 and 49999. For layer we can keep the current range of -1000-1000 (though +/- 21000 would be possible).
Foreground/Background handling (which btw. seems to be broken for quite some time) is now also compatible to the current version (and doesn't interfere with layering anymore): All images with layer < 0 and images with (layer=0 and base-y < 54) are background, the rest is foreground.
Please comment: http://yavin.mogsoft.de/~mog/wesnoth/layers.diff
Aurë entuluva!
-
SkeletonCrew
- Inactive Developer
- Posts: 787
- Joined: March 31st, 2006, 6:55 am
The patch applies cleanly in my terrain branch so I see no reason to consider waiting for merging with my branch.
The line "//vertical_images.clear();" can be removed.
I personally would prefer to make constants from 100000 and 50000 since they are used in 2 seperate functions.
Can be changed to "int base_y = itor->first % 100000;"
I haven't tested with this patch yet, but if it works I'd say comit it. I don't see the slight chance of breaking non-mainline WML as a big problem, since that will also happen when my branch is merged. The terrain graphics have no backwards compability.
Code: Select all
void terrain_builder::tile::clear()
{
flags.clear();
- horizontal_images.clear();
- vertical_images.clear();
+ images.clear();
+ //vertical_images.clear();
I personally would prefer to make constants from 100000 and 50000 since they are used in 2 seperate functions.
Code: Select all
+ int base_y = 0;
+ base_y = itor->first % 100000;
I haven't tested with this patch yet, but if it works I'd say comit it. I don't see the slight chance of breaking non-mainline WML as a big problem, since that will also happen when my branch is merged. The terrain graphics have no backwards compability.