It does the same thing as PLACE_IMAGE except the created item may
use the same submerge code as units. If not placed on water there
will be no submersion effect. If placed on water it will be submerged
to the same level a unit would be submerged to. In general physical
items placed into water should use this, whereas items placed on top
of water should use PLACE_IMAGE.
The new macro has been applied to the merfolk cages in the Bay of Pearls
scenario in HttT.
This will usually be determined by the monitor's refresh rate,
but also is rounded down to provide some leeway. It also limits
according to the draw_delay preference.
The loading screen now uses this to limit event calls.
When loading into different screens prior to actually starting or joining a game, Wesnoth loads the configs of all add-ons, otherwise it wouldn't know to display eras, campaigns, etc for selection. However starting with a4e8ac3, when loading all add-ons the `active_addons_` variable was no longer being populated with any of the the add-ons that were active. This meant that when checking to see if any of the active add-ons had changed it could falsely determine that nothing had changed and therefore could skip the step where it actually deactivated add-ons.
As an example of the current state prior to this fix:
* Player starts Wesnoth and joins the multiplayer lobby -> all add-ons are active, but `active_addons_` is empty.
* Player joins a game with no add-on content required -> Wesnoth checks the add-ons required for the game (none) against the contents of active_addons_ (empty).
* Wesnoth therefore determines that it doesn't need to deactivate any add-ons since it thinks no add-ons are active, when in fact all add-ons are active.
* Out of sync errors then happen if any of the players that join have add-ons installed that can globally affect other unit_types, such as [resistance_defaults], since those add-ons haven't been correctly deactivated.
The fix then is to make sure that game_config_manager::set_enabled_addon_all() correctly populates active_addons_ when it's called.
Fixes#6650
The blend function SDL (and for that note all GPU frameworks) uses
is incorrect when compositing transparent source pixels onto a
transparent destination. I added a note with the correct blend
function, for possible future implementation.
- Detect obvious cases of inheritance loops
- Don't try to keep track of tags with a super tag that exist within a conditional tag
- When searching for a tag path, don't append the leaf to the full path
Every place it's called already passes a default-constructed config, so this won't affect any existing code.
The removed assert is pointless when it'll be cleared by the call, and the two places that called that function also passed a default-constructed config already, so it was doing nothing.
This sets up writing both the cerr and cout streams to a log file, as well as pulls the log rotation logic out of log_windows.*pp into the general logger.
Note that this is meant for usage on macOS and Linux, not Windows. log_windows.*pp has additional functionality in it, as well as a fair bit related to the --wconsole option.
Draw call overloads taking source regions have been removed.
textures now can have a source region set, using set_src() to set
it in draw-space, and set_src_raw to set it in texture-space.
This source region is automatically used when blitting.
texture constructors were also cleaned up.
The portion of the window that the game canvas covers is now what is
returned by video::input_area(). This is in display coordinates, which
may not match draw coordinates or output coordinates.
sdl/input.cpp was changed to query and account for input_area when the
mouse location is polled. This removes the input dimension caching that
was previously being done.
All other uses of input_area() are probably erroneous, as SDL events are
automatically converted to draw-space by SDL. It is only needed when
polling the mouse location directly, which returns it in display
coordinates relative to the window.
This ensures sveral things:
* the game display's offscreen render buffers are used correctly
* custom render targets will report the correct draw area
* they will also report the correct clipping region and viewport
* converting draw space coordinates to output coordinates will
return the correct coordinates on the full render target.
Not much of this is currently used, but it will be necessary to get
correct for source clipping regions and possibly input conversion.
These are both on the TODO list to clean up.
Theoretically the drawing area may change if we are rendering to
texture. However the vast majority of cases wanted the game canvas
size independent of whatever the current render target may be.
A function game_canvas_size() was also added returning a point,
and this was used to simplify things where appropriate.
* faked() has been renamed headless() to better express its meaning
- it is true when there is no window or renderer at all
* internal usage of the window pointer has been clarified
- a window should always exist, unless in headless mode
* non_interactive() has been removed in favour of headless()
- they are logically identical
* some nomenclature internal to video:: was clarified
- fake_interactive_ -> testing_
- fake_size -> test_resolution_
- init_fake_window() -> init_test_window()
- make_fake() -> init_fake()
- update_framebuffer_fake() -> update_test_framebuffer()
* any_fake() was replaced with testing() to check if running tests
* make_test_fake() was removed in favour of set_resolution()
- the only other use was for init which can be done... in init()
There are now two clear non-standard modes: headless() and testing().
Headless mode has no window or renderer, and hardware rendering
should never be attempted.
Testing mode has a window and renderer, but there are not currently
any tests which use them. Rendering functions may be skipped.
