doofus-01 wrote:What sort of animation are we talking about here? I was thinking the fountains and swirls on the top of the towers, and some small sparkles or wiggles on the straight parts, which wouldn't involve anything special and there could be non-animated sections.

Yes, only those.

I don't think my previous idea of reversing the keep-to-castle images makes sense after all, so I think the remaining options are:

1. Simply animate the current tiles. For the aforementioned reasons, I'm not really a fan of this idea, since that's going to require a huge pile of images even if you leave some select sections unanimated.2. Leave the straight parts unanimated, but create separate fountain/swirl images which can be placed on top of the towers by the same corner method as the aquatic camp keep stone posts are.3. Animate the water with palette cycling (color cycling, palette shifting, palette rotation...). That is, re-paint the water with a fixed palette in such a way that it animates nicely when that palette is cycled, which I think could be accomplished with ~PAL and/or ~RC.

That last one is something I just came up with right now, and I'm not yet even completely sure if it'd work. I also haven't really worked with palette cycling myself so I can't say how hard it would be to actually draw something like that.

P.S. I've been kind of busy trying to implement support for optional macro arguments because that'd really help with a lot of this terrain graphics work.

I've opened a PR for some straight wall variations: https://github.com/wesnoth/wesnoth/pull/875For now, it only has wooden walls that are probably mine walls (terrain code Xom). I also plan to make a plaster/whitewash wall (Xoi), for interior walls that aren't part of a gloomy castle.Here is a screen-shot of the wooden walls:

Spoiler:

----------------------------------------------

zookeeper wrote:1. Simply animate the current tiles. For the aforementioned reasons, I'm not really a fan of this idea, since that's going to require a huge pile of images even if you leave some select sections unanimated.

OK.

zookeeper wrote:2. Leave the straight parts unanimated, but create separate fountain/swirl images which can be placed on top of the towers by the same corner method as the aquatic camp keep stone posts are.

That would make life easier, and probably wouldn't look too bad. Let's go with that as the fall-back method, if we can't come up with something better.

zookeeper wrote:3. Animate the water with palette cycling (color cycling, palette shifting, palette rotation...). That is, re-paint the water with a fixed palette in such a way that it animates nicely when that palette is cycled, which I think could be accomplished with ~PAL and/or ~RC.

That last one is something I just came up with right now, and I'm not yet even completely sure if it'd work. I also haven't really worked with palette cycling myself so I can't say how hard it would be to actually draw something like that.

I don't know either, but is there anything wrong with using ~BLIT()? Then we can just have some 3-frame-animation little squiggles carefully crafted pixels slapped onto the castle images, they can be reused wherever the walls are aligned.

zookeeper wrote:3. Animate the water with palette cycling (color cycling, palette shifting, palette rotation...). That is, re-paint the water with a fixed palette in such a way that it animates nicely when that palette is cycled, which I think could be accomplished with ~PAL and/or ~RC.

That last one is something I just came up with right now, and I'm not yet even completely sure if it'd work. I also haven't really worked with palette cycling myself so I can't say how hard it would be to actually draw something like that.

I don't know either, but is there anything wrong with using ~BLIT()? Then we can just have some 3-frame-animation little squiggles carefully crafted pixels slapped onto the castle images, they can be reused wherever the walls are aligned.

Sure, we could just make separate overlay animations and place them with ~BLIT (or with separate rules, perhaps).

Anyway, I did make a simple little proof-of-concept, which actually does work in-game (and wasn't difficult at all):

zookeeper wrote:Anyway, I did make a simple little proof-of-concept, which actually does work in-game (and wasn't difficult at all):

Looks nice, though I'm also unsure about the slope on the straight part. Is color-cycling less resource-intensive or something, what's the reason for it? Is there a specific color table I should use?---------------------------------------I've updated the walls variation PR:

In a theoretical hardware-accelerated Wesnoth, colour-cycling would probably be less resource intensive. As it currently stands, it should be about the same as if the frames were each a separate image on disk. At most there'd be a slight difference at load time, but I have no idea whether that would be better or worse than having them as separate images.

However, having fewer image files does help keep Wesnoth's download size lower, so there's that.

doofus-01 wrote:Looks nice, though I'm also unsure about the slope on the straight part. Is color-cycling less resource-intensive or something, what's the reason for it? Is there a specific color table I should use?

No reason aside from not needing separate images for animations (which I think is a pretty big boon). It actually works really easily:

1. Put this inside [color_palette] at the end of data/core/team-colors.cfg:

2. Append ~PAL(water_blue_1 > water_blue_[1~4]:200) to the image path (I've tested this by simply editing NEW:CASTLEWALL).3. Sample the colors from the above hex values, or from the attached image.4. Paint the parts you don't want to have any color cycling with other shade(s) of blue.

Of course, you don't need to actually use my palette, you can come up with your own. However, I do think 4 colours works nicely at this scale; 5 seems like it would be overkill, and 3 might work but is probably much harder to make look smooth.

Now, if you want to do this, please don't worry about the WML or making a PR at all. I'm currently refactoring some of the macro internals so a simple image dump would be perfect.

Sorry I've left the fountains moldering here, I do mean to do something with it at some point...

In the mean time, I've made what I think are some improvements to the gates/portals/doors. We'd tried to have one terrain code per portal (rusty gate, open wooded door, etc.) and the orientation would be automatic, but after stepping away from it for a while, I came back to find it pretty annoying to use. I've got a PR here: https://github.com/wesnoth/wesnoth/pull/1839 and it has some minor improvements, but most important is that it allows map-maker to control the orientation, just like the bridges. Unlike the bridges, it doesn't have elbows and tees, because I think the concept is not realistic, and you can always just use a wall terrain, like in the lower-left of this

screen-shot:

The N-S facing images are still a bit problematic, but they are useful in some circumstances.

ZIM wrote:Maybe you could also try to make the ruined version of elvish castle?

Like a razed castle, or like an old castle "returning to nature"?

ForestDragon wrote:I think it would be nice if you made a ruined version of the tall encampment keep (I forgot what it's called).

Maybe, but I think there is less need for it. For established undead facilities, there is the regular ruined castle. This last thing was for "bad-guys on the move".-------------------------------Anyhow, in order to feel like I'm being useful while still avoiding work on the unfinished scorpion stuff or the fountains on the aquatic castles, I've got a new floor terrain. I've got a PR here:https://github.com/wesnoth/wesnoth/pull/1936

screenshot

I was trying to avoid just making a square version of the cobbles, but these may be too big/rough. The transitions aren't finished.