It uses a shared_ptr, to prevent crashes during play_controller
initialization. But it only holds a weak_ptr, to preserve
previous behavior of skipping whiteboard ops when the ptr is
NULL.
It requires also for us to construct the whiteboard before
constructing the gui, so that we have a valid pointer to pass.
Most likely all of the managers will have to be moved forward,
in this commit we move forward the whiteboard and pathfinding
module, anticipating future commits.
Also refactor editor and game_display to use this.
To achieve this it turns out we also have to add a "dummy display
context" unique to the editor code, which it can use to initalize
editor display, because after refactor NULL doesn't cut it
anymore. This appears in src/editor/editor_display.?pp, might
want to branch into its own file later.
This commit makes all the necessary changes to allow
display::get_units() to return a const unit_map rather than non-
const, and to eliminate display::get_const_units(). This allows
us to eliminate a const cast introduced in prior commit.
In leader_scroll_dialog, unit_animation, and some places in
unit_display, we change the call display::get_const_units to
get_units, and mark the return type as const.
In unit_display::unit_attack, we can't do this because that fcn
also calls unit::take_hit which is part of the game logic and
should not become const. We make that function take a reference
to game_board instead and pass resources::game_board from the
caller. Also we pass display in as an argument from the caller,
to improve encapsulation marginally.
This was made possible because const units may now be drawn and
animated. There are some clients of the display object that still
call display::get_units, which is a non const getter, and which
we support by a const cast. The next step of refactor is to get
rid of that, but in this step we have at least gotten rid of all
internal uses of the non-const unit map.
If we decided it was worth it to inline map_location ==, then
surely this is also worth it to inline null_location, as the
compiler may be able to reduce tests for == null location to
"x == ... && y == ...", without having to move to a different
compilation unit.
This overwrites an existing flag animation for a side with a rebuilt
one, intended for use after changing a side's flag animation.
It does pretty much the same thing init_flags() does sans vector
allocation and TC configuration, which are supposed to have been done
already.
In order to implement functionality to change a side's flag imageset
after display initialization has taken place, we need to rerun this code
under different conditions.
The refactored code default-initializes the set of flag animations prior
to building them for individual sides; before this change, only the
memory allocation for the set was reserved in advance. Since the first
time init_flags() runs is during display initialization,
default-initializing the set shouldn't really make a noticeable
difference.
Now, we assign the flag animations later over the default-constructed
animations. Hopefully this shouldn't introduce any new interesting bugs.
It's not like there's any code accessing the animations at this point.
There is also a remnant in preferences_display.cpp, where
two resolution options below 800x480 are in a hardcoded
list (scr_modes), but I do not know if there might be a
reason to keep those.
This will later allow WML/Lua to lock the viewport so the user cannot
scroll away from the current viewport location. WML and Lua actions such
as [scroll], [scroll_to] and [scroll_to_unit] will always be able to
scroll the screen regardless of this setting.
