It turned out that alot of compilation units were using resources
but not including the header, and only getting circuitously
through the display.hpp header which got it from unit.hpp. This
is an improvement since unit itself doesn't need the header,
and most classes probably don't either.
The remaining uses are just, checking whether or not the pointer
is null, or resets to its value, or simply storing it in a local
variable.
It might be appropriate to add resources::game_map back as a
function taking no parameters, at least this is flexible
enough to be changed later easily.
This is the result of running, in src/ directory, the following:
find . -type f -exec sed -i 's/resources::game_map->/resources::gameboard->map()./g' '{}' \;
and carefully inspecting the result, and adding "game_board.hpp"
This is the result of running command, in src/,
find . -type f -exec sed -i 's/\(WRN.*\)\\n\"\;/\1\" << std::endl\;/g' '{}' \;
and inspecting the results.
Also ran this subsequently:
find . -type f -exec sed -i 's/\(WARN.*\)\\n\"\;/\1\" << std::endl\;/g' '{}' \;
which only affected render.cpp
utils::wide_string was a std::vector<wchar_t>
On most unix systems, this is 32 bits wide, and therefore a UCS-4 encoding.
On windows however, wchar_t is 16 bits wide, and the naive approach results
in UCS-2, which can only represent the Basic Multilingual Plane.
Most functions that used wide_string have been moved over to ucs4_string.
The Win32 API has been moved over to a specially created utf16_string instead.
Specialty tolower #ifdefs have been removed, as the towlower function has
been available since OS X 10.3, OpenBSD 3.7 and probably ancient versions of
all other BSDs too. The only issue is that on windows, the function cannot
be applied to characters outside the BMP.
Codeblocks made some of my tabs into spaces and I had to fix it.
Also, forgot to mention this before, but I cleaned up some of the code
for astarsearch.cpp as well.
In many places, std::copy was used with back_inserters, or other
std::inserters. These have in most cases been replaced by using the
ranged insert member function of each stl container. Firstly, this makes more
readable code. Also, this is often more efficient because,
if the compiler can find the distance between the source iterators,
it only has to make one block allocation and then fill it
with values. In other cases, containers were being default constructed
and then std::copy'd into with some form of inserter. These were cleaned up
by using the iterator range constructor instead.
Use of std::copy was especially egregious in the case of associative
containers such as map and set. Sometimes back_inserter was
being used, other times std::inserter set at front, but it doesn't matter
because there is no front or back when inserting, and it's much cleaner
to just use set or map::insert(iterator begin, iterator end).
1) Dehardcoded the terrain symbol icon.
2) Use mix colors for mixed terrain in the minimap.
3) Show colored terrain symbol in the help browser.
4) Don't show magenta colored empty symbol for offmap locations.
Most notably, the name of the ability/special is now in the message,
addressing bug #20716. Firings are also limited to once per ability/
special per game execution.
white for "normal" (that is, same as movement cost), yellow for
"worse" (more than movement cost), and green for "better" (less than
movement cost). This should work out better for players, as it plays
against the default of vision costs equaling movement costs.
This is a general overhaul of the class embodying movement types,
featuring:
* Better data encapsulation
* Less duplication of code between unit.cpp and unit_type.cpp
* Easier to use
* New files for the class (VC and XCode projects still need updating)
* New (shorter) name for the class
Some additional revisions will be coming.
The primary motivation for this was to get a class that embodies
movement costs (part of the data encapsulation).
...and update various parts of the code to call it (instead of using
unit_type_data::find() to "find" a known unit_type).
There was one call in the editor's code where I am unsure if there are
supposed to be side effects other than building the unit_type. So I
left the code as-is and just added a comment for someone else to
evaluate later.
