UI elements with blur effects (such as translucent windows) now defer
rendering for one frame, so they can snapshot the area underneath
for blurring.
In the future this should be done as multiple passes in one frame,
but for now this is fine.
Windows will now render to an offscreen buffer. They only render when
something changes, and the re-rendered area is kept to a minimum.
When the window needs to be redrawn to the screen, it simply copies
the appropriate region from the offscreen buffer.
This should greatly improve performance in cases where a window isn't
changing its contents, but needs to be redrawn frequently. For example
a pop-up dialog being drawn over animated terrain (see #7615).
Fixes#7988
I have no idea why this helps anything at all, since my understanding has always been that inner joins vs a big where clause are essentially two different ways of accomplishing the same thing, but changing the two inner joins to a where clause improves query performance from 6.3 to 0.012 seconds (when running the query from the website VM). As best I can tell from the explain plans, the inner joins are somehow confusing the query optimizer to use the game_content_info table as the starting point of the query instead of the game_info table, but why it's doing that or why it has such a large impact remains a mystery.
* update falcon and raven races to not get names
To conform with other monster units
* units: remove a redundant line of code
from races falcon and raven definitions
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
With this it puts the player back to the title screen after showing
an error dialog, so it's not much better, but at least it's not a
crash.
Fixes issue 7164. We weren't able to work out what caused the file corruption
reported, but I believe it's a race condition about saving while the AI is
recruiting. The file in the bug report has a `[snapshot]` tag with
`init_side_done=yes` but without a `playing_team` attribute, which must be the
result of `game_state::write()` when not in the `PLAY` phase. Loading such a
file causes `game_state::start_event_fired_ == false`, and triggers
`play_controller::start_game` to call `replay::add_start_if_not_there_yet`.
The i18n'd string is reused from `game_launcher.cpp`.
