This will never reduce the drawing resolution beyond the minimum window
size specified in preferences/general.cpp.
The minimum window height has been reduced from 600px to 540px!
This is to that a 1920x1080 display can use a pixel scale of 2.
It could be changed back, but a better solutuion would be updating the
default theme to accomodate this form factor.
There is a new sdl::get_mouse_state() function that should be used in place
of SDL_GetMouseState() in every case. It returns coordinates relative to
the drawing surface.
With this, the pixel scale option seems to be working without issue.
Rendering is now done to a separate surface. All routines that previously
wrote directly to the framebuffer now write to this surface. When the screen
is flipped, this surface is copied directly to a streaming texture, which is
then scaled to the window's rendering surface for display.
This has enabled a drawing resolution that differs from display resolution.
It is active and for the most part works. Input events are converted to the
correct scale by SDL, so most input handling routines can be used unchanged,
but one or two are causing problems so there are some bugs. To test this,
change the "pixel_scale" preference. Don't expect a playable game with
any pixel scale other than 1 yet.
Turn the 4 side setup of the firststrike_and_laststrike test into a macro
called `COMMON_KEEP_A_B_C_D`for reuse in other tests.
The comment for `GENERIC_UNIT_TEST` gets a couple of extra paragraphs.
All the files get wmlindent run on them, which reindents `FAIL_IF_NOT`.
The main reason for having these is separate files is Git's fuzzy-patch
matching when merging and rebasing. Having large blocks of identical text
in `wml_unit_test_macros.cfg` can mean the wrong section gets patched.
This reverts commit 9caf43ed732f621d6d752ff5dede54466d5d4b4c. I was mistaken, this is actually meant
to check if mouse_focus_ is a styled_widget or not, and if it's not, fire events unconditionally.
This has been here since 2009 when this block of code was added (0d72daac2e1157f0d069ff07eb359a9581272cdc).
It's not clear mouse_focus_ would ever be null here, but if it ever was, this would have tried to deference
it and crash. To be safe, I've wrapped both fire() calls in a not-null check.
* GUI2/Distributor: further cleanup started in 988bf973e96efaed9eec268c8d1ba5f4ed3bed37
This restores the template to mouse_button, but it keeps the struct-based approach for specifying ui_events.
This returns a label handle which allows you to remove, reposition, or replace the label later.
In addition to all the features of wesnoth.print, you can now specify where the label appears onscreen, as well as a fadeout time separate from the duration.
You can also anchor the text to an edge or corner instead of centering in on the screen,
specify the maximum width it can occupy as an absolute width or a percentage,
and specify a background colour and transparency.
It includes a demo scenario that demonstrates many of the capabilities of the API.
To play the demo scenario, run with -toverlay_text_demo or select it from the in-game test list.
Sadly, this takes the campaign up to 100 string changes between 1.16.2 and
1.16.3. The only one of these that was already going to change for 1.16.3 is
S04t's volcanic forge one.
(cherry picked from commit a1e60f061dd85237215966e5733a8da8f7ec126b)
As reported on the forum in https://forums.wesnoth.org/viewtopic.php?p=672374#p672374
If a unit with "last strike" ([firststrike] special with apply_to=opponent, on any of its attacks)
was targeted by other unit for attack, wesnoth crashed.
Fix similar problems for other weapon specials like poisons, when two users of specials with
apply_to=opponent fought, one fighter only could be poisoned or slowed.
* Add a unit test for poison
* Add a unit test for firststrike and laststrike
