It occurred if so many add-ons were installed that the credits text surface
needed to be split to two, and it affected all text until restarting
Wesnoth.
I literally do not remember writing this with the false argument. Anyway, it meant the
screen area was saved in screen coordinates and not pixels, which caused crashes on certain
systems.
The loss of new_haloes in commit 80d42597b8eb701e3cef40c7890fcb0bc402450e also meant that a halo
was scheduled for the next halo_impl::render() run only when the previous
halo was unrendered, i.e. in the next frame. Thus, when the unit halo was
recreated when the unit was moving (a temporary fake unit, and together
with it, the corresponding halo, is created every time the unit steps into
a new hex), the new halo didn't show up for one frame.
Fixed by adding every new halo into invalidated_haloes immediately.
1. Makes it clear to the player that the loop is not a bug by adjusting
and clarifying objectives & adding a scenario repetition counter.
2. Allow campaign to end by leader death on fourth repetition instead
of second to better convey endlessness/hopelessness feeling, with
music & dialog to match.
1. So forthcoming objective changes work correcly in linger mode.
2. So forthcoming objective code is simpler.
3. Allows jumping directly to scenario in debug to work correctly.
* Removed display::screen_area(), display::w(), and display::h().
* Moved the global screen_area() function into the CVideo class.
* Renamed CVideo::getx() and gety() to get_width() and get_height()
* Made those two functions return the result of screen_area() instead of the other way around.
* Added preliminary support for high-DPI rendering to screen_area()
Note on the last point: When I fixed bug #1772 (aa8f6c7e7 right now but will probably change with rebasing)
I noted that SDL_GetWindowSize and SDL_GetRendererOutputSize returned the same results for me (even with
Window's automatic scaling for non-high-DPI-enabled apps disabled) but that the SDL documentation stated the
former returned screen coordinates and the latter pixels. In that same commit I changed the dimension functions
to use SDL_GetWindowSize. I've now reversed that decision and gone back to using SDL_GetRendererOutputSize so
I can guarantee output in pixels. If use_pixels is false, the code will return coordinates in 96 DPI, so I need
to have pixel measurements for the calculations.
Again, though, I do not know if SDL_GetWindowSize returns a different value that pixel size (which it's said
to do) on macOS or iOS. I'll need to do some testing. It's possible on those platforms I won't need the 96 DPI
measurements, but it's also possible it will be needed on on platforms, since all of our code relies on pixel
measurements.
The problem is that a line that's too wide to fit into the window
invalidates the layout of the entire window, and the window will lay itself
out the next time it will be drawn, after the Lua console code has scrolled
it to bottom.
The easiest fix is to simply defer scrolling to bottom until the window has
been drawn (and thus laid out) next time.
This moves all the warnings flags from the strict build to the regular build, except for -Werror. This means that the only difference between strict builds and non-strict builds will be if warnings are turned into errors.
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.
Closes#2257. This fixes instances where save_index entries created *before* the relevant
binary paths were loaded resulted in leader images without TC when viewed in Game Load
even once the relevant paths were loaded.
Do note as of 3b0eb6b986f722d this likely isn't a problem unless the save_index file is
deleted, since otherwise all relevant save data (including independent image paths) will
be created in-game when they're saved.
One thing to note, though, is @newfrenchy83 mentioned that the final autosaves of games
were lacking TC in the Load Game dialog. *This* change should fixe that, but I don't know
if the above change affects that too.
Prior to this, if you saved a game with a campaign-specific leader sprite and exited the game
or reloaded the cache *without* opening the Load Game dialog, the leader image would appear as
Unknown. This is because the save_index entry (and the accompanying path expansion) only occurred
when the save was selected in the dialog.
This change ensures all saves' leaders' images from here on out will always appear in the Load Game
dialog (unless, of course, the save_index file is deleted).
