Render engine changes

[SkeletonCrew]

I've been busy with changing the render engine, the goal of the changes
is to get a z-order (layer) based system. I just finished converting all existing
rendering to use the new system. I did some initial testing and it seems to
look oke but more testing will be required.

boucman wants to look at allowing to use multiple layers within unit
animations. I want to look at allowing more items to be drawn in front of
units, but that will be another time another thread.

These changes allow us to draw terrains in front of units again, which I did.
(If this is unwanted it can be reverted with swapping two lines of code.)
There's a big glitch; most units on a keep have their standing frame out of
the hex (which is a bad thing (tm)) and get decapitated.

The question is do we want to keep units behind certain terrains and if so
what's the best solution to avoid them loosing their head. Upon request of
mesilliac I've drawn the health bars in front of the terrains, does that look
good or should it be behind the terrain if the unit is behind the terrain.

[Alink]

About the decision for the terrain in front of units, it will also force to use a feature that I often tried to push: render unit under fog and shroud when they are at its edge (obviously this is because if unit is under terrain and terrain is under shroud, then unit must be under shroud). So thanks, it's already make shroud edge less ugly.

For the same reasons, I think that keeping the hp/xp bars on top of everything is better. This allow the unit's bars (and so the unit's presence and its orb) to be visible even if partially shrouded. This will also avoid the problem of a tower or a tree hiding the important lower part of the hp bar. I also saw some talk on IRC about more transparent hp bar. I don't think it's a good idea, it creates possible confusion with the underlying terrain or unit, and the alpha blending will modify the color of the bar, which can also be misleading. In fact, I recently tweaked bars to make this kind of illusion less frequent.

The only more serious hiding that I noticed is ellipse of a unit behind a keep and at ground level. But it's rare and I think it's ok, since we can also rely on orb and team-coloring (and often race).

I suppose we can maybe modify the image if a terrain causes problems. Like just removing few leaves of big trees or using some transparency.

Now for the hard part, the out-of-hex unit problem:
I think we already discussed that but I suggested to sort the render order by using first perspective (and so the y position), then use the layer ordering. But when I introduced it for melee fight, I remember that some people didn't like it for missiles and wanted arbitrary layers, regardless of position (to allow things like always draw missile on top of units, even if they comes from south), so maybe we also need some special layers to allow overriding this.

My point is : not using perspective as the main ordering will probably bite in some special cases (keeps, moving units, big animations, future new objects etc...). Only exceptions must be special object not having a clear altitude and position (like UI info and possibly missiles).

I also suspect that unit moving to south will give some work. Probably need to be rendered on top of foreground terrains after the first pixels move, or maybe check the height of destination and render the unit under the background terrain if it's higher than the unit's altitude.

I didn't study all the new code, but with this new implementation I suspect that using less main layers and more drawing_order with a value like y*1000 + a "sub-layer" parameter (with unit image using 0, background ellipse using negative values and foreground terrain using bigger values) may works. This hopefully will fix the decapitation issue, preserve the flexibility for ellipses etc, and maybe even allow possible tricks like slightly shifting some values by using y-offset of moving unit or height of terrains.

Anyways, the foreground terrain system looks good and I really like the new potential code simplification, since we will now be able to organize drawing calls in a more readable way (before the rendering order fixed the coding order, preventing to group similar things)

EDIT : Just did a quick test with the previous sub-layer idea (thanks to this flexible design, it was only few characters to change, even if it's completely modify the layer use). This indeed fix the decapitation issues and seems to not introduce new bugs. It doesn't fix the attack on keeps issues, maybe I will try the height and y-offset tricks.

Posting the patch just to illustrate the idea (the "y*1024" was already there). With also a little tweak fixing a possible error about temporary unit passing behind other higher unit.

PS : Sorry, I realize now that this post start to be too much code related for the art forum (and also too long) :-/

[yobbo]

I don't have much to add, except that I would really like to be able to have terrain drawn in front of units.

Here's an example using current Wesnoth SVN with the healthbars over the terrain.

Also, I found another example of the terrain drawing problems when a unit attacks from the north of a great tree. He's half drawn through it. The great tree is one image, so from a WML point of view, this should never happen.

[Jetrel]

Things:
Rendering the unit under fog and shadow when it's at the fog's edge -> Good.
Rendering the hp/xp bars on top of everything -> Good.
Rendering the ellipses at ground level, meaning they'd possibly be obscured -> probably not a real problem.

Also, I found another example of the terrain drawing problems when a unit attacks from the north of a great tree. He's half drawn through it. The great tree is one image, so from a WML point of view, this should never happen.

This is absolutely correct; multihex graphics like the trees and villages should (in final effect) be drawn as though they were single, unbroken images. I talked with mordante, and this is not the case - they're apparently diced into hexes, and drawn one by one.

Fortunately, if we have a z-indexed drawing engine, this should be relatively simple to solve - just make all subparts of a a multihex object use the exact same z-index as their "parent" part. Here, let "parent" mean the hex that the user clicks on in the editor to place a village/tree (the one that actually is that terrain). E.g. the one that the tree/village building actually touches the ground in.

[Eleazar]

Rendering the unit under fog and shadow when it's at the fog's edge -> Good.
Rendering the hp/xp bars on top of everything -> Good.

The fog isn't a big deal to me, but is probably better drawn to overlap units.

The HP bars and orb and crown, star, hero icon, whatever should be definitely drawn above all terrain and unit layers. They are not "real" objects in the gameworld— they don't have a position, they should always be visible, in front of everything, or turned off.

Rendering the ellipses at ground level, meaning they'd possibly be obscured -> probably not a real problem.

IIRC your worst case scenario isn't the keep, but a hex of flat-ish terrain in the middle of a lot of mountains— which can obscure a unit a lot more than the keep does. IIRC it can completely cover the ellipse.

I don't like the fact that the ellipse can be so frequently covered, but there is no better alternative if the terrain covers the unit at all.

Some of the tall terrain should probably be edited to minimize excessive overlapping, if we keep the overlapping.

[Iris]

Mihoshi asked me to post this:

About rendering - I'd do it this way. First static objects (i.e. terrain) are drawn and resulting bitmap and a map of depth for each pixel are stored. After that, each frame only dynamic objects (units, animated terrain objects) are rendered over reused terrain bitmap.

Not sure how that can be done, but AFAIK OpenGL has just right tools for that.

Disregard the OpenGL part, of course.