For testing purposes and feedback mostly
Also set the level for debug to 3, to get messages related to native resolution and scaling from the new hidpi gui scale code
uint64 is unsigned long on linux64 (first match in
configure:find_type_with_size), so the format should be lu, but this is
incompatible with Win64, so just cast to make it portable and warning-
clean.
Amends commit 1496ad6bb5.
When an engine is added or removed, it affects the embedded resources in
scummvm.rc, so config.mk is required.
+ Add some missing dependencies in win32.mk.
Building for Android (OpenGL) had noisy warning for hiding overloaded virtual function
Added a dummy implementation in OpenGLGraphics manager, and also for OpenGLSdlGraphicsManager it now explicitly calls the SdlGraphicsManager implementation for the void argument signature.
Example:
../scummvm/backends/platform/sdl/win32/win32_wrapper.cpp:39:52: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'VerSetConditionMaskFunction' {aka 'long long unsigned int (*)(long long unsigned int, long unsigned int, unsigned char)'} [-Wcast-function-type]
39 | VerSetConditionMaskFunction verSetConditionMask = (VerSetConditionMaskFunction)GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "VerSetConditionMask");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The call to MIDIGetNumberOfDestinations() starts the MIDI server which takes
3-4l seconds even on the modern hardware. We are querying this in the GUI Options
which then lags on the first launch.
Thus, we are creating a separate thread and make this call at the start of
ScummVM, so by the time the user gets to the GUI, the server is already launched
and there is no lag.
Of course, that would mean that we will launch MIDI even for the games which are
not using it, so this is a tradeoff for the better UX.
If the user keeps one finger down they can still generate new right click events
Previously in multitouch events, we supported only one right click event starting from one finger down.
The user subsequently had to restart the multitouch mode for another right click; hence lift all fingers
from the surface and start again.
New behavior allows user to generate a new right click while holding one finger down and putting down and lifting a second finger.
I think this is more intuitive and user friendly, although it might require some getting used to, if one was accustomed to the old behavior
