These provide a simple and consistent way of storing variables inside
[micro_ai] tags in unit variables. This is needed for fixing a bug
with variables stored in units from a previous MAI causing problems
with a subsequent MAI.
moved 2 preferences::.. calls out of the loop so that we just call it once.
the following is especialy true on large maps, all results are recorded from a msvc 2010 release build, and recorded with the msvc 2010 sampling Profiler.
these calls are less expensive than the final scale_surface_sharp call at the end of the funcion. But if you assume the scale_surface_sharp woudn't be there, then they'd use a major part (~50%) of the cputime of get_minimap.
i also tested replacing scale_surface_sharp at the end of the function with scale_surface. Here are the results:
tested on LotI Mp Map (part of LotI addon) which has a size 200x200 with fog but no shroud, no logs, ingame debug mode enabled (the :debug wesnoth-console command).
the image on the upper middle is made with scale_surface the other two are made with scale_surface_sharp.
The down-left Image are the profiler results from the scale_surface version of get_minimap, the down-right are from the scale_surface_sharp version. The record was started shortly before a moving so the record only shows the cputime during moving. Also the content of this commit is used in those testings.
http://i.imgur.com/YETVuNq.png
the profiler shows that during movements (with fog) more than 50% of the cputime of wesnoth is spend in scale_surface_sharp for get_minimap, and i personaly think differences in the minimap are not worth that. But there are different opinions and thats why i didn't change it yet, but i still propose replacing the last call
minimap = scale_surface_sharp(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
with something like:
if(map.w() > 100 || map.h() > 100)
{
minimap = scale_surface(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
else
{
minimap = scale_surface_sharp(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
note, that the 100 is choosen rather randomly.
If that's a problem with msvc then i propose wrapping it in a #if.
I have heared that we will be able to do scaling with hardware acceleration later (around september), but i don't see how thats a reason to not do this until then.
since we can't attack these, this information is not useful.
afaik it is quite common to have permanent "statues" in MP maps,
and extremely rare that units may be unpetrified in any core or
umc scenarios.
logic error was introduced in client side controller types:
when a player drops and controls an ai-side, the side_drop signal
is only sent to the host, who should make that side a local ai,
not a networked ai.
WML values may not be used as keys, this can make savegames invalid.
Store information in the units now rather than in self.data. (Note:
storing in self.data would also be possible if the syntax were changed.)
In the default configuration, the AI moves the messenger which has
advanced the furthest through the waypoints first. If this key is set,
the rearmost messenger is moved first.
For two of the CAs this mostly just means reading the [filter] tag and
picking one of the messengers. However, for the CA moving the escort
units, it means a complete rewrite, as the AI now needs to figure out
which escort unit should be moved toward which messenger.
When there were lots of escort units, they previously quite frequently
blocked the messenger’s way, preventing him from making progress even
when it was possible. Escort units now specifically move out of the
way if they do not need to attack enemy units in the messenger’s way.
in blindfold_ii, blindfold was taken off when local side takes control
in this fixup, blindfold is taken off as soon as host gives control of
any side.
to achieve this, playturn.cpp must be able to ask the playcontroller to
remove the blindfold.
we create a virtual method of play_controller, on_not_observer,
which is called whenever this client gets local control of a side
(it becomes ai or human)
on all play_controllers except play_mpcontroller, this does nothing
in play_mpcontroller it calls a "remove_blindfold" function
when a human side takes control, remove_blindfold is still called,
as a precaution.
By correcting the assignment of the cost of the unit it now correctly
says whether or not the play actually has the gold to recall a unit, as
after this check it is assumed they do by the program which creates
the possibility of recalling when you have no gold, or negative gold.
Added comments so that the magic number is explained.
