There's really no reason to have this anymore. It was (AFAIK) introduced years ago
as a performance-saving measure, then was moved to Advanced Preferences in 1.13 since
modern PCs mostly have no issues. With accelerated rendering, there's even less of a
reason to have this.
This changes:
utf8::char_t -> char
utf8::string -> std::string
utf16::char_t -> char16_t
utf16::string -> std::u16string
ucs4::char_t -> char32_t
ucs4::string -> std::u32string
utf16::string and ucs4::string are now proper strings instead of vectors of characters too.
In order to get this change to compile at all, I needed to add a ucs4_convert_impl::convert_impl
specialization for wchar_t alongside the new char16_t specialization; both point to the same
conversion implementation type.
This commit doesn't do any additional cleanup. I'm sure if we looked, we could get rid of a
lot of the custom conversion code and probably a bunch of stuff that might have had to do with
supporting utf16::string and ucs4::string being vectors instead of basic_string specializations.
Either way, I don't know the code (or encoding handling in general) to make a call as to what's
needed or not. I'll let someone else do that.
The vgettext() function, while declared in src/formula/string_utils.hpp,
actually has its implementation out-of-line in
src/formula/string_utils.cpp where GETTEXT_TEXTDOMAIN is defined to
"wesnoth-lib". Because vgettext() is implemented in terms of the _()
function (an inline wrapper around translation::dsgettext()), it passes
the textdomain defined in the file where it was implemented as a
parameter.
This means that every case of vgettext() being used in other code units
where GETTEXT_TEXTDOMAIN is not defined to "wesnoth-lib", is broken if
the string being looked upon doesn't coincidentally exist in the
wesnoth-lib textdomain.
Ages ago, to work around this limitation, an overload of vgettext() that
takes the textdomain name as a parameter was introduced (see commit
0ba3d05204). Since this form of vgettext()
is rather unwieldy to use (and in particular, the xgettext message
extraction tool mistakes the first argument for the msgid, see below), a
VGETTEXT() macro was also added that uses the GETTEXT_TEXTDOMAIN symbol
defined in the file where the call is made, and thus we get the correct
string from the correct textdomain.
Switching all cases of naked vgettext() in mainline to VGETTEXT() fixes
a myriad of situations where an interpolated string that has an extant
translation does not actually get translated in practice because of the
mismatched textdomain reference (see issue #2709 for an example with MP
game titles). I couldn't find any cases of the companion vngettext()
function (which handles plurals) being used in the wild naked, but for
future reference it also has a companion VNGETTEXT() macro to pass the
correct textdomain to its textdomain-parameter overload.
One caveat is that this commit DOES break the string freeze in one
particular case -- src/units/unit.cpp has a case where the
textdomain-parameter version of naked vgettext() was in use with
"wesnoth" as the first parameter, and xgettext misidentified this as a
translation entry for a "wesnoth" string in the file's assigned
textdomain (which is the default textdomain, wesnoth). So this will
result in the next pot-update both removing the spurious "wesnoth"
string AND adding the correct string to the relevant catalogue template
("<span color=\"$color\">$number_or_percent</span> HP").
to that textdomain.
Other than that, I believe this does not break the string freeze in any
other fashion and it shouldn't result in any regressions for i18n.
It might be worth considering in the future renaming vgettext() and
vngettext() to names that make people less likely to misidentify them as
functions they can freely call directly without regard to the textdomain
assignment issue.
Even though we switched to encrypted local password storage a while back, any passwords
saved with the old plaintext method remained in player's preferences file and were loaded
by the game where there's no reason they couldn't have been directly accessed.
It makes more sense as a game to start with fullscreen enabled. As for the default res,
it's unlikely to be used (only crops up if the saved resolution value is invalid), but
it makes sense to use a more modern widescreen resolution.
The proliferation of game_display::get_singleton() was due to 786233d5c9
where I replaced resources::screen (itself a game_display* pointer) with the game_display singleton.
Using the game_display pointer has already caused one case of UB (issue #2447), so I figured it best to
call the base class pointer in all cases where a game_display-specific function or override was not used.
This is consistent with the use of display::get_singleton() (in fact, it's the same
pointer). It also makes the code more readable, and means we get to further clean up
the resources set.
A few of them are quite small, so this has no performance effect on those, but a few others
are potentially quite large, such as the one in campaign_server.cpp.
* Added a point ctor that takes an SDL_Point.
* Added a toggle_fullscreen function to CVideo.
* Change all management of resolution data to use point instead of std::pair<int, int>. This
shortens the code considerably.
* Cleaned up preferences_dialog::set_resolution_list
* Made CVideo::set_resolution return a bool indicating whether resolution was changed.
* Swapped which of the two set_resolution overloads contains the main implementation.
* Moved the events::raise_resize_event() call when setting resolution to the CVideo function
where it should have always been (instead of the prefs dialog callback). This is a pretty
essential component and having it localized in one place meant any other area of the code
that might have called set_resolution wouldn't have it.
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
This a two part commit. First:
----------------------------------------------------------------------------------------------------
Added and deployed two new helper macros for the standard implementations of the static execute
and display functions. I also made use of a variadic template in order greatly simplify code
maintenance. Now, even if the dialog's ctor parameters change, no one has to worry about updating
the associated execute/display functions (though of course, this only applies if the helper macros
are used). \o/
I did not deploy the macro in cases where there were multiple overloads or the functions did more
than just show their dialogs. I might add an additional __VA_ARGS_ parameter to the macros later.
Do note for the end_credits dialog I moved the default empty-string parameter from the display
function to the ctor.
Second:
----------------------------------------------------------------------------------------------------
Another change is that modal_dialog::show and modeless_dialog::show no longer take CVideo arguments.
Since the video argument couldn't be included in the parameter pack (maintaining the argument would
have meant making it the first one, which would be just as much work), and using CVideo::get_singleton
in the macros would require adding video.hpp includes in a whole bunch of files, I simply removed the
argument. I had been intending to do this for a while anyway.
This therefor also removes the CVideo argument from:
* All dialog display/execute functions.
* modal_dialog::show
* modal_dialog::build_window
* modeless_dialog::show
* modeless_dialog::build_window
* wml_exception::show
* gui2::show_message
* gui2::show_error_message
* gui2::show_transient_message
* gui2::show_transient_error_message
* gui2::show_wml_message
* gui2::build
* gui2:🪟:window
* gui2::dialogs::tip::show
* Various GUI2-related Lua functions. The video_dispatch helper was also removed.
* Any functions that took a CVideo argument for the sole purpose of passing it to one of the above.
Ya know, all these damn CVideo arguments didn't actually do anything, besides an occasional check to
CVideo::faked. At the end of the pipeline, they just got assigned to the video_ member of gui2::window.
Huge code bloat for nothing.
These have no effect in the GUI2 lobby, nor do I intend to make use of them (plus the lobby has
its own sort controls anyway). I'm assuming they were for the GUI1 lobby.
This fixes#2156.
preferences::add_acquaintance replaces the existing friend entry if the given username
has already been added to the acquaintance list, but the prefs dialog always added a
new row unconditionally. I've changed it to only add a new row if the username creates
a new entry, else replace the appropriate exiting row.
@gfgtdf explained in IRC that it's often used to slow Wesnoth down (instead
of speeding it up, as I had assumed).
This should also allow unit tests to compile again.
The FPS cap, originally implemented in 2007, is very poorly done. It
doesn't take frame time variance into account, and is therefore almost
guaranteed to cause missed frames all the time. It doesn't increase timer
granularity on Windows, which causes SDL_Delay() to often take much longer
than intended. And it's hardcoded for 50 FPS, which fits poorly with 60 Hz
displays.
This new implementation fixes all those issues.
My experience is that the game feels much, much smoother with the new
implementation, perfectly competitive with 1.12. In my opinion, performance
is now at an acceptable level for a stable release.
The game now supports @ or = in usernames for the purpose of saving them to a file.
Though I don't think these are allowed currently, it's probably better to
support it from the start rather than having things break if they later
become allowed.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
