...of theming works.
Was not able to get higher resolutions work nicely, the ThemeWML seems
to have a problem when specifying main map values >1024x768...
...but my attempt to write RANDOM_FEATURE_PLACEMENT with the map
dimensions as implicit arguments completely failed. Maybe one of the
real WML wizards can do better.
...not only the one under the mouse
More consistent with the highlighting of the unit's sprite and prevent
a sort of false de-selection feeling when the bar darkening
Thanks to uso for the idea.
It seems that after the scrolling and before the move, orb & bars were
briefly visible and this also trigger an assert.
Now always hide orb and bars of fake unit, and allow the drawing unit
function to know if it's a fake (and so skip undefined stuff)
the problem is that placing alignment right of level sometimes make
alignment vanish (eg when hoovering over the units in the first
scenario of two brothers)
...(only possible to use if --enable-small-gui is set at configure
time), it is not active by default because several places are
currently rather broken (mp creation/lobby, load dialog and
preferences show many glitches), there is currently no support in the
editor for such a low resolution
fix support of 800x600 be decreasing the minimap size when at a
resolution below 1000x620 improve tinygui display
...now if they see the player, all nearby guards are woken up to
pursue the player (and go to sleep again if the player disappears from
sight). Also, removed the starting encampment and made the player
unable to accumulate any gold.
...tinygui should now basically look like "normal" guie beside using a
smaller font, most of the object placement at 400x300 and upwards is
exactly like normally (eg end turn) in 320x240 only display of weapons
and hp/xp is improved
This helps bug #11030 (lower the risk of confusion with colors under
the bars, caused by terrains or by the unit, like the drake burner's
wing or the elvish fighter'sword (who always look near AMLA). Also
useful on snow terrains. Maybe the 0.3 value must be tuned. This also
compensate a little the change of the alpha of bars from the previous
commit (brighter bar but darker background)
...(used when a unit is not under the mouse, 1.0 continue to be used
in this case) This helps a little to avoid confusion with a colored
background partially visible under the bar (like reported in bug
#11030) PS: bars a bit more visible but seems still ok (if you can
notice the change). Using always 1.0 is possible and more KISS but
looked less nice IMO