Something is processing events during render, but finding it is
more difficult than just aborting drawing when the vector of
drawables gets invalidated.
Once that is fixed nothing will be changing the drawable vector,
so this will then have no effect. Until then it will cause some
flickering when resizing, but it won't crash.
Fixes#4460.
Also fixes the seconds-long UI block at the start of a scenario and
when beginning story view at the start of a campaign.
And thus, also fixes the new visual fade-in effect which was completely
broken by music fade-in blocking everything.
Note that this fix does cause fades to happen in a non-blocking manner.
Old music will fade out in the background, then the new music will
fade in once the old music has finished fading out.
Squashed from new_rendering:
* Ported over the basic text texture cache
* Font/Text: fixed bad hashing leading to duplicate textures
* Use text texture drawing method instead of surface one
* Cleaned up and optimized pango_text rendering pipeline
* Font/Text: removed get_width and get_height in favor of just get_size
* Font/Text: guard against caching a null texture
This breaks the credits screen. The game will crash when it tries to
display it.
This has been megasquashed because it was a month-long mess of fixes
and reworks.
In summary:
* objects no-longer draw by hooking a DRAW event. In stead they
inherit from gui2::top_level_drawable, and implement its interface.
* the game display now renders to an offscreen buffer. This is used
to implement hardware scrolling, and to redraw after halos, floating
labels etc. move.
* halos, floating labels, tooltips, and a few more things are now
drawn on top of the game display, rather than as part of it. This
allows them to be updated independently without reading pixels
from the screen.
* surface restorers have been removed. Reading pixels from the screen
should now be unnecessary excepting two cases: (a) screenshots,
(b) background blur. Blur is cached, and screenshots are occasional.
* GUI2 widgets no longer keep track of dirty state. They are redrawn
as necessary. Most places which previously set dirty state now queue
a redraw in their part of the screen in stead.
* A consequence is that active translucency is enabled across all UI
elements, and the game display can (and does) continue to animate
while menus and dialogs are showing.
* performance is drastically increased for basically everything, most
notably map scrolling, floating text, and halos.
* CPU usage is drastically decreased. With animations disabled it is
essentially zero while nothing is moving.
* GPU usage is also minimal. The display is only flipped if something
is drawn.
There is a new global interface draw_manager which handles drawing,
and a new abstract base class top_level_drawable (TLD) to indicate
that an object is something that has a place on the screen and should
be drawn.
Basic usage is fairly straightforward. Top-level objects (such as
windows) inherit from top_level_drawable. They must implement the
functions layout(), screen_location(), and expose().
layout() should ensure that screen location and animations are current.
screen_location() should return the current draw location on screen.
expose() should do the actual drawing.
The draw manager keeps track of what regions of the screen, if any,
need to be redrawn. Regions must be invalidated by calling
invalidate_region(rect). This can be done at any time other than during
expose(). It must not be called during expose().
The draw manager has one main callable function, sparkle(). This may
be renamed at some point. It manages calling the TLD functions on all
TLDs in the correct order. It also manages loop delay and vsync.
The standard game loop now becomes:
1. events::pump()
2. draw_manager::sparkle()
The only suggestion that came up was checking to see if something in this file changed between when the vcpkg cache is used vs isn't used, so... print out the contents of a random dependency and then check back later I guess.
This makes the Xcode build's way of locating headers be similar to other compilers.
The header maps feature means you can include any header in the project just by the filename,
but none of the other supported build systems allow this, requiring a full path relative
to the src directory.
By disabling header maps, Xcode will give an error if you miss the file path
(unless including a file in the same directory).
Previously, if a map file (as opposed to the map_data key) contained a map error, it was possible to get to the side setup screen, and the error message did not appear until the "I'm Ready" button was clicked, at which time the game fell back to the main screen. Now, trying to click "Create Game" pops up an error dialog and the game remains in the Create Game dialog.
Changing the error from using VALIDATE() to throw means that it creates an in-dialog error, rather than a WML exception that falls back to the main menu.
