...and tips of the day box by using the general window/menu borders
instead, making the title screen look IMO considerably better. Also
affects the campaign menu, but that too looks better to me this way.
...this time using 2 32 bit values instead of 1 64 bit value tested
more than the previous version and also tested the speed
regression. The speed regression is much lower than with the 64 bit
version.
...the implementation with a single 64 bit value gave both compiler
and performance problems. It will be done again with a different
approach. Didn't revert the changelog since it gave conflicts and
this feature will be added again soon.
* converted the cold resistance of the Elvish Sorceress line to a holy
resistance
* decreased the holy resistance of the Orcish Assassin line from 20%
to 0%
It enlarges the glitch that terrains at the edge of the screen don't
get drawn properly. The top row no longer draws overlays eg villages
and forest only have a base terrain. Since this problem is next on my
todo list anyway I don't bother with it too much right now.
It uses a 64 bit datatype which might not be supported by all
compilers so I added a compatibility header but can't test that since
my compiler supports 64 bit integers. I didn't see a license issue
with this header if others do see an issue feel free to remove the
header... Then I have to find another one.
Keys: - x,y : position
- side (default=1): side number
if side=0 check if the village is not owned
- new [store_owned_villages] tag to store all the owned village by a side
Keys: - variable : variable to store in
- side (default=1): side number
- terrain (optional): list of terrain types
If side=0 store all the unowned villages
If terrain is present matches the villages against the list of terrain types
smarter logic for join/observe
- prevents a crash when there is a delayed change in the gamelist
- save the game_item "id" (could also be used for minimap cache lookups)
...not all code honours this yet
the default is 50 fps
changed the draw delay logic it now determines when the next draw
should take place, this avoids adding a delay when the code is already
lagging. That problem occurs with scrolling and animations. The engine
now stays much closer to the desired fps, provided that the system it
runs on is fast enough.