After some discussion, we concluded that this code was unmaintained, not even used in
some places (display.cpp, units/frame.cpp), leaving the only area that really used it
at all the image surface cache. Considering there was never really a conclusive benchmark
of its benefits and because said surface cache will be used a lot less going forward,
we're just removing it and simplifying everything for everyone.
Closes#1260 since it's now irrelevant.
Closes#2914.
This doesn't break the string freeze since it reuses a format string
from the same textdomain required by gui2/game_version for the exact
same purpose.
This covers several things:
Instead of creating a new worker thread manually and having it set class member state flags,
I instead utilized std::future and std::async. As far as I can tell, this should avoid the
(albeit unlikely) potential race condition wherein the ls could close before loading at all
if the thread was delayed in starting.
Removed the timer interface and split it into two components:
* A drawing callback that handles the animation. This has its granularity retained at 100 ms,
but can be easily adjusted if we want it to go faster.
* A pump monitor that runs much more frequently (every time events::run_event_loop is called,
technically). This handles checking the state of the std::future object and will then close
the window. This makes the loading screen a bit speedier compared to the previous iteration
since it no longer wastes time waiting for the next timer callback to close.
The one bit I'm not 100% sure about is the check for the future object's ready state in the dtor.
Though, relatedly, I wonder if perhaps we should wait for the worker thread to complete in that
case instead of exiting....
Also shuffled a few things around, such as immediately setting enter/esc disabled in pre_show
instead of waiting for everything there to finish.
Do note there occasionally seem to be a few odd issues with the dot animation after this commit.
Will look into that. But it may be some texture cache-related issue...
This also cleans up some unused log defines and a VS 2013 conditional include.
Turns out remove_const alone only removes the const from the pointer, not from the type
itself, so the expression wasn't returning true. This strips the pointer out before removing
const and matches against char instead of char*
The code was checking that the From type was either char* or const char*. Replaced it
with an equality check against char* with the const stripped from From so both match.
dispatcher::has_event called the private find() function, which after a whole bunch of
jumping around essentially checked that the signal queue for the given event was not
empty. This was a run-time op, yet the code was set up using SFINAE in order to for
has_handler::oper() to call the event_signal function corresponding to the event's queue
(ie, the mouse queue for a mouse-type event).
Since this code was written before the era of constexpr, event type validation was done
using boost::mpl, which, in this case, resulted in a monstrous amalgamation of build-time
template specialization for a run-time check. I'm not certain, but I believe it might
have resulted in an specialization of find() (or at least, implementation::find()) for
every single event type (each member of the ui_event enum).
This converts the code to a purely run-time check and throws out all the template stuff.
It also removes the relevant event_signal overload dealing with events in a set. The
version dealing with function types is preserved as it's used in the fire_event()
implementation and is a fairly standard usecase of SFINAE.
The has_handler class has also been converted to a static function since it's no longer
needed for template specializations in find().
And finally, is_raw_event had to be renamed to is_raw_event_event to allow simple name
completion in IMPLEMENT_RUNTIME_EVENT_SIGNAL_CHECK. I could have also renamed the raw event
queue to signal_raw_queue but I figured keeping the name as signal_raw_event_queue made
its purpose clearer.
These are used to hide an add-on from listings and deny the author the
ability to upload or delete it or change its passphrase. This is
meant to be used when enforcing add-ons server rules that do not justify
deleting all of the add-on's metadata (for example, issues with icons or
descriptions).
This changes the order in which the hook_post_erase hook (currently
unused in production and fully untested) is fired so it will be run
*before* displaying the confirmation message to clients. This might need
to be changed at a later point if the hook functionality ever gets used
again, but for now it'll do.
Turns out that commit broke TC on unit images in messages since it broke the equality
check in lua_unit.cpp. Added the XBRZ IPF as part of the Lua unit portrait attribute
instead.
I *think* this is the proper place to do it.
[[noreturn]] is supported on all the compilers we support. Still need to decide
the exact minimum versions and figure out what to do with DEPRECATED and FALLTHROUGH,
so leaving those for now.
And since we require VS 2015 and up we can enable C99 unconditionally.
This is no longer needed with the compilers we support. It is needed on VS 2013, but
we dropped that. Don't know when GCC or Clang stopped needed it (if they ever did).
I'm guessing the "function that returns a value cannot be bound in a function type
that returns void" behavior wasn't an intentional design. Additionally, I don't believe
point 1 raised in the accompanying comment has ever been true... if so, pretty sure
we wouldn't have been able to build at all.
Also removed unnecessary global.hpp include from functional.hpp.
This was never fully implemented and has been essentially abandoned. If we want to
add this again, we should look to adding full game controller support (Steam controller,
for example), though I don't know how suited this game is for controller support. As for
as I can tell, the only working part was ever map scrolling.
Includes a sqrt -> std::sqrt conversion I forgot in this file awhile back.
