Idea: Forest drawn as overlay

[Shundread]

Suggestion:

While loading the images (I dunno when it happens), create "copies" of the terrains that will have forests and draw the forest over the copies. While drawing the map just draw the copies.

This way you have one draw instead of two.

Anyway, not all terrains should have forests... as far as I know so far, only plains and tundras have forests... am I wrong?

-Shundread

[quartex]

Yes, and the program considered forest and snow forest as the same terrain. If we start creating hill forest, or sand forest, then we'd have to create new terrain types with new movement and defense values, which just gets too complex. We have enough terrain types as it is, I see no reason to have other forest types. KISS is my opinion on this topic.

[Darth Fool]

This technique (even if not generally used for forests) could be used for implementing temporary terrain changes (ala grove-master who turns terrain surrounding a village into forest while she is on the village)

[Neoriceisgood]

and dwarven digger! who turns surrounding terrain in cave.

[Christophe33]

I think the overlay of a terrain is usefull buth should be restricted to "artificial" construction like bridge, road, village and castle. It makes things easier from a graphic point of view since you don't need then to make every variant of a bridge (and pier and stone bridge?) over terrains that can be bridged. Also double alias tag allows a bridge river to be consider either as a river or as plain for a unit (the computer choose the best mvt and defense). So composite terrains are possible. You could get a mountain village with a defense of mountain (if better than normal village) and so on.
BUT, I don't think this should be use for forest. The only case it would be worth it is with the toundra but you really don't gain much since you already did the snow forest. The transition problem with hills (and mountains) could be addressed by setting up additionnal transition rules:
for transitions between two "tall terrain" (hills, mountains, forest), you use the transition from the terrain located south (also southwest and southeast) of the other.

[telex4]

BUT, I don't think this should be use for forest. The only case it would be worth it is with the toundra but you really don't gain much since you already did the snow forest. The transition problem with hills (and mountains) could be addressed by setting up additionnal transition rules:
for transitions between two "tall terrain" (hills, mountains, forest), you use the transition from the terrain located south (also southwest and southeast) of the other.

To me, the overlay solution looks much more elegant. You have fewer graphics needed, and no new complications to transition rules. I can't see any reason in what you say why the opposite would be better... so can you explain why?

[Dave]

Suggestion:

While loading the images (I dunno when it happens), create "copies" of the terrains that will have forests and draw the forest over the copies. While drawing the map just draw the copies.

This way you have one draw instead of two.

But if you're going to do this, why not just have the artists do the 'copies' themselves, and have them as pre-rendered images?

The most appealing aspect of frame's suggestion is having the forest overlap other terrain, but having the ground not overlap. Pre-rendering into one image like this wouldn't let this work.

David

[Dave]

There is another problem to be considered here: efficiency. Many people already complain that Wesnoth is running slowly on their older machines.

This would surely have some efficiency hit, though hard to say how much. Probably quite significant in a screen full of forest.

David

Would this be slower than drawing transitions on top of other terrain?

Yes, it would be slower. Transitions are typically almost entirely transparent images, and Wesnoth uses Run Length Encoding (RLE) when it blits. That means when you have a mostly transparent image, it will jump over an entire transparent row in one operation.

Blitting a forest on top is probably the worst possible situation, since it's likely to be an intertwined mix of higher and low alpha pixels.

That's my initial reaction though. Exactly how slow it'd be is difficult to say -- programmers are notoriously bad at estimating the efficient and inefficient parts of a program.

I do think this idea has some merit. I think it'll ultimately be up to Ayin whether it makes it in or not, since he's the developer in charge of tile rendering now.

David

[Eleazar]

Yes, and the program considered forest and snow forest as the same terrain. If we start creating hill forest, or sand forest, then we'd have to create new terrain types with new movement and defense values, which just gets too complex. We have enough terrain types as it is, I see no reason to have other forest types. KISS is my opinion on this topic.

Quartex, Frame's method wouldn't neccesarily entail the creations of new terriain types, (i don't think we should have more either) The program should only allow the forest to appear over flat terrain, (grass, dirt, snow, maybe sand +swamp) but that would just be a graphical effect. But if it has the trees, it's a forest square, and in it the Elves will rule. (Every other transparent tile that I know of determine the terrain value. A villiage hex is the same terrain-type wise weather its over snow or dirt.

I'm rather confident that this method will allow better in-game graphics Weather it's worth the trouble is open to debate.

[Sangel]

The ingame effects aren't problematic here - we already have the capability for multiple aliases (Bridge = Shallow Water + Grassland), and Forested areas would obviously just be a multiple alias terrain.

More important, I think, is whether the performance hit would be significant. It's no problem for me, but we are trying to cater to older machines here as well.

Is there any chance that Frame could produce a "sample" forest for this method, and Ayin could add a little code to test the performance impact? If it was too costly, we could always go back to the old method.

[freim]

Forest and Snow-forest drawn as overlay have now been added to cvs. No noticable performance hit. Dave have also been doing some profiling of the code lately and made quite a few significant performance improvements.

There are some glitches to work out, but it already look quite good IMO.

Known issues:
* Trees should be drawn over villages, not under.
* Forest in front of castle don't get drawn correctly.

UPDATE: Variations and alpha shadow on the forest.

Some screenshots:

[Elvish_Pillager]

Some screenshots:

HOLY MOLY! They look... er... just like they do now. Except for the shadows and the slightly glitchy looking place where the snow forest meets the grass.

[Eleazar]

i think they look better.
Also this system makes terrain making easier and more flexable.

[Invisible Philosopher]

Making the game far slower would of course not be good at all. I can't image how drawing a few castle tiles can slow down the game that much...?

The same thing happans when setting 'Time Areas'. I have a nagging suspicion that they are getting drawn on the fly, as opposed to drawn and cached. . .

Yes, which forced me to use an ugly workaround in my scenario The Spider's Fang (which includes above-ground and underground in the same scenario) : I made my own [time] tags that didn't adjust the color differently for underground and different times of day outdoors, and made a stupid excuse for it in the scenario.

I have the same suspicions of the innocent-looking [terrain] tag....

On the contrary, the reason [terrain] is so slow is because it's recalculating the cache for the whole map each time you use it.

[Jetrel]

I like these a lot, and am glad there were no issues with performance.
The forest seems unfortunately a bit darker than before, but, hey - no big deal.



One thing, though - hopefully before you do too much work on these...

The snow forest seems rather two dimensional - part of the problem being that the trees are being drawn from an almost side-on perspective. Because they are so darned small, there is no problem with the tops, but there is with the bottoms of the tree.

I have realized that this is also true of the normal forest, but there it is not a problem because the trees have leaves which are similar in apparent color to the trunk.


The trunk at the bottom being visible should be rare. From our perspective, the base of the tree would form an ellipse - not a horizontal edge. I feel that this is too common in the snow forest tiles.

So, here is an attachment which shows which trees I think look good, and which look bad.

Good luck.