Namely complete_redraw_event(), recalculate_minimap(), and redraw_minimap(). I had
been keeping the last around for reference (see f5ec886cb5) but I
figure it's not really worth it since this isn't the drawing method we'll want to
be using in the end anyway.
This is to avoid confusion with filter_context::get_disp_context. display used to
inherit from filter_context, but that was refactored out a while back. I left
get_disp_context since it was used and useful, but I realize now it causes more
confusion than not.
Also converted help::load_terrain_types_data to use get_map() directly since I
noticed it.
And changed a stray use of `thedisp` to `disp` in unit_drawer. Doesn't do anything
but it was bugging me.
Instead of a pointer to a member of a derived class, used a virtual function implemented
in both derived classes (game_display and editor_display) that return an reference to the
appropriate object.
Also removed the overlay.hpp include from display.hpp. We can forward-declare the overlay
struct.
They're still in the game_config namespace but are now in a more logical header.
game_config::version has been replaced with wesnoth_version.str(), save for one case
where it was replaced with wesnoth_version directly (it was a comparison against another
version_info object; no need to compare against a string...).
Also cleaned up a bunch of game_config.hpp includes.
Report drawing was handled in draw_sidebar, so that function was also removed. The display
class won't be handling sidebar drawing anymore anyway.
Also removed display::invalidate_game_status and game_display::invalidate_unit which were
both used to set a flag dealing with report drawing.
This should finally get the display class close to map drawing only.
Design change from 075a9bac34.
After discussion with @celticminstrel, we decided it better for the controller to
own the UI object as well as the display object, instead of the display owning the UI.
I've added a pure virtual function declaration to controller_base to ensure all controllers
implement this.
I decided to go with a modular approach, where both in-game and editor UI dialogs inherit
from a single base class, a pointer of which is owned by the display class. That can be
used for common functionality that needs be shared by all in-game dialogs.
Right now the new UI is just static. It works with most stuff, but not key presses. Working
on that...
This was the core of the surface-based drawing engine. Unused now. The drawing_queue_add()
calls throughout the code have been left, but commented out, for reference while reimplementing
things. The actual drawing_queue code has been left to, since its layers are referenced in
places. Need to remove them.
* 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.
This is primarily focused on getting various areas of the game display drawing, such as footstep images
and the terrain defense indicators.
To facilitate the last, I've refactored draw_text_in_hex to utilize floating labels instead of drawing
to hex directly with surfaces. This probably isn't the most optimal solution, since labels are continuously
created and destroyed, but since their text is usually short and cached in the rendered text cache it
does for now.
Also includes some cleanup of deprecated functions in display, and slight reordering of drawing order of
certain elements.
I've moved the terrain hex drawing code directly into draw_visible_hexes instead of relying on get_terrain_images
to return a vector of all the necessary images for each visible hex and then drawing them. Instead, we now draw
each hex's images immediately without any intermediary container.
With the old method, after about 10 to 15 seconds of drawing we had already allocated (and destroyed) almost 180,000
temporary vectors (a new one was created for each hex, twice per draw cycle). It's obvious how quickly that would add
up over a normal play session, and though in this case the performance hit for creating each vector was probably tiny,
creating them likely would have added up.
Previously, every visible hex was iterated over and every element in that hex draw. This was inefficient
for two reasons: First, it meant the performance footprint for many operations like unit drawing was O(n²),
since the list of elements had to be checked for every single hex. Second, it meant the renderer had to
switch active textures many more times than necessary.
My new system involved drawing every element of a specific type at once - ie, all background terrains at
once, all units, all items, etc. This reduces lookup time from O(n²) to O(n) and results in a noticeable
performance increase. It also reduces the number of times the renderer needs to switch active textures,
since bulk draws such as the map grid overlay are now done all at once while that specific texture is
active.
There are still some layering issues and missing elements that need to be sorted, especially in game_display.
This removes all the code related to invalidating locations, any functions used to set, modify, or propagate
location invalidation, and several functions that no longer serve any purpose anymore since their only purpose
was to handle invalidated locations.
In particular, this allows the player to choose the filename before saving,
including the extension. If support for target format is present, Wesnoth
honors the extension and saves the screenshot in that format.
I also changed the default screenshot format back to PNG due to quality
issues JPEG has with pixel art. See discussion in pull request #2655.
This commit doesn't introduce any string changes. I used existing strings
for everything (sometimes having to take them from another textdomain).
