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.
On the advise of 8680, the unicode string was replaced by the hex
transcription of the corresponding codepoints (which he kindly
provided).
This might help to pass the overzealous encoding check of clang.
This commit also fixes a discrepancy between the signature of u8index in
declaration and definition.
For manipulation of UTF-8 encoded strings (insert, delete, truncate, and
size), usually conversion to wstring and back was necessary. This has
two disadvantages:
* the size of wstring is implementation defined
* the
double conversion is slow
The purpose of this patch is to add functions
to handle these tasks by a layer handling the different indexing between
codepoints and characters.
This commit applies these functions in
several places to replace the old implementations.
The byte_size_from_utf8_first() implementation will be replaced in a
separate commit as it relies on the count_leading_ones function by 8680.
Signed-off-by: aquileia <sk.aquileia@gmail.com>
The problam was that mp::configure is not used for reloaded games and so
mp_game_settings will not be fully initialised. This leads to using default
values rather than values set using mp::configure screen or from reloaded game
config.
The optimal solution would be to either display mp::configure for reloaded games
or to populate mp_game_settings using reloaded game config. However, both
solutions require rather a lot of code restructing and are probably not suitable
for a feature freeze.
Changed from cfg["foo"] > number, to !cfg["foo"].blank(). Turned a cfg call into
just a default assignment. Added a .to_int to a cfg["foo"] call to prepare
against bad user input. Finally added whitespace to 2 lines to get them to line
up with the rest of the lines.
Here the changes to get whiteboard to work are mostly cosmetic, the
right cost for each unit is displayed on the unit in question. This
is mostly for peace of mind as the user looks at the screen they don't
get confused. The proper gold is also taken for each recall and
replaced for each canceled/undone recall while in whiteboard.
The previous implementation was not strongly exception safe.
This code is nearly identical logically, but with strong exception safety.
It's also good practice and more readable.
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).
Halos are never rendered for shrouded locations, but they are still
unrendered for them. A long-standing issue with [item] halos resulting
from this is that a halo that gets rendered to the screen at least once
for an unshrouded location later causes glitches if that location is
manually shrouded afterwards.
This can be avoided by not unrendering halos for shrouded locations. I
believe this solution makes sense because halos for shrouded locations
are never rendered first, and if the location is shrouded later on, the
display code will redraw the affected locations and overlay shroud on
top, causing the halo object's unrender buffer to become hopelessly
obsolete.
at a certain point in playcampaign.cpp after the level has ended, wesnoth was
grabbing .child("end_level_data"), and writing carry_over sides.
this would cause "mandatory child missing" errors in the test case described.
we fix the error by checking if the child was not present and if so adding it.
however, it may indicate a more fundamental bug involving reloaded games.
