It is implementation-defined whether the file position returned by `ftell` denotes the beginning or the end of the file when opening in append-mode. This was causing the condition `io_tell(File) == 0` to always be true, so the CSV header was also written to `ddnet-saves.txt` every time that a new save code is written. Now, we check if the file already exists before appending and only write the CSV header once when the file does not exist yet.
Only ban DNSBL blacklisted players once when joining immediately after the DNSBL result is available, to prevent current players from having their runs ended when the `sv_dnsbl_ban` setting is enabled.
Note that enabling `sv_dnsbl` and `sv_dnsbl_ban` at the same time will still cause the players to be banned immediately. To prevent this, first enable `sv_dnsbl` for at least one tick, then enable `sv_dnsbl_ban`.
Closes#2640.
* Refactors the previous code segment
* Fixes 'auto' GPU identification and display in DDNet Graphics tab of
the settings. The 'auto' GPU is the best one encountered in the VK
physical device enumeration array until we encounter one that is
at least "integrated" when accessing them in increasing order
* Selects the first GPU that matches a name when using one by user
specified name
Add support for touch input to the engine, UI and console. Ingame touch controls require more discussion and will be delivered separately based on this engine implementation.
Engine
------
The state of all currently pressed touch fingers is aggregated based on the SDL touch events and can be retrieved with the `IInput::TouchFingerStates` function. This design is less complex than an event-based system where the touch events are delivered to the individual client components, as each system would then have to keep track of the finger states individually. However, this means that only one component can handle touch fingers at any given time, which seems like a reasonable assumption for our use cases.
Obsolete code for relative mouse handling on Android is removed. Connecting a mouse to an Android device should now also work as expected, as more recent SDL/Android versions support relative mouse input natively.
User Interface
--------------
Support absolute mouse positioning and clicking in the user interfaces (menus, editor, demo player) with touch presses.
Support right clicking by pressing and holding one finger at roughly the same position for 0.5 seconds.
Support scrolling scroll regions up and down with a two finger swiping gesture. Fast scrolling via a two finger flinging gesture is not yet supported and would be a useful future extension.
The menus and demo player are fully usable with touch inputs. The editor is only fully usable with an external keyboard and/or mouse, as panning the map is not currently possible with only touch inputs, which is also left as a possible future extension.
Console
-------
The touch input logic for the user interface is reused for the console. Thereby, text selection in the console with touch input works, although the text can only be copied by pressing Ctrl+C with an external keyboard at the moment. In the future, we could add buttons to the console to activate the search and copy functionalities with touch inputs.
Support scrolling the console history up and down with a two finger swiping gesture.
The local/remote consoles can currently only be opened with an external keyboard. The ingame touch controls will also include buttons to open the consoles.
The `in_channel_count` and `out_channel_count` properties of the `SwrContext` were already deprecated and have been removed in the most recent ffmpeg library version, hence rendering demos was causing an assertion error when these properties were set.
For newer ffmpeg versions, we now set the channel layout with the `in_chlayout` and `out_chlayout` properties instead of setting the number of channels.
Starting the server on Android is currently not possible because a) the server executable is currently not compiled for Android b) launching the server executable with `fork` and `exec` is not supported on Android and may result in strange bugs like broken networking.
Running the server in a background service or in a separate process by using `Runtime.getRuntime().exec` from Java code might be feasible, but this is currently too much effort and may be done in the future.
For now, the "Run server" button as well as the process related system functions are disabled via conditional compilation on Android, to prevent the networking bug that would otherwise be triggered by pressing the "Run server" button.
