When rendering directly to the output buffer, we need to maintain the
state of what has been drawn and what needs redrawing per-buffer.
We previously tried to do it implicitly by checking `SDL_DOUBLEBUF` and
other flags. The previous implementation was broken in several
ways, resulting in rendering issues on devices that support 8-bit output
directly.
Changes this mechanism to explicitly maintain buffer state per output
buffer. The new mechanism doesn't require knowledge of the number of
buffers, and thus also works correctly with triple-buffering.
Fixes#5447
Introduces a `ControlDevice` global which is distinct from `ControlMode`
in that it is set to `Gamepad` even when simulating a mouse.
This allows us to avoid a number of edge cases related to mode changes.
Fixes#4242
The gamepad cursor (inventory, spells etc) no longer relies on warping a
real mouse cursor. This should make things work better on platforms that
do not support this, like Wayland.
Disabled by default because of these known issues:
1. When clicking on inventory item, it briefly appears a bit shifted (in the wrong coordinates).
This issue can happen with software cursor as well, but is a lot more
obvious with the hardware cursor.
2. Cursor is scaled with nearest-neighbour scaling, which may look a bit different from
how the rest of the graphics are scaled.
See also previous attempt: https://github.com/diasurgical/devilutionX/pull/955 by @viciious
Co-authored-by: Victor Luchits <vluchits@gmail.com>
Previously, we always loaded entire videos in memory before playing them.
`libsmacker` does not provide a streaming API but it does provide a
`FILE *` file pointer API.
We now take advantage of the `FILE *` API by streaming the videos on
platforms that support `fopencookie`.
This means faster startup and less memory usage on these platforms.
This option completely disables all audio handling, including audio
loading code and dependencies.
Dialog text length is estimated to be somewhere between
Cain and Griswold speed.
- Add file documentation to about 1/4 of the files in Source
- Copy over a lot of the documentation from the sanctuary/notes repo
- Standardise all the existing documentation
- Create a configuration for Doxygen
- Add more documentation (engine.cpp is now fully documented)
Now diablo.h is treated in the same way as all other header files of
Source, as it only contains the declarations of global variables and
functions of diablo.cpp.
Besides consistency, this also enables mods to include diablo.h just
like any other header file without having to include every header file
(and without having to include C++ specific aspects of the now all.h).