The string memory pool mutex lock/unlock were lost during the
merge of String and U32String. This caused the cloud feature
to randomly crash for example when synchronizing savegames or
downloading game data.
If the debugger load command was given a folder path instead of a path to a file, the game would crash
Also, legacy save (debugger) command should not accept a folder path. The code supports only a full path to a filename. It will not provide an automatically generated name for the legacy save when given a folder -- maybe a tweak to consider for the future, but probably not a thing to bother with.
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");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With __printf__, MinGW prefers the portable old ms-style printf, and
warns if formats like %lld and %hhd are used.
In practice, if __USE_MINGW_ANSI_STDIO is not defined, it defaults to 1
on C++11, and these formats are supported. Using __gnu_printf__
suppresses bad format warnings.
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
Thierry Crozat
antoniou79
Orgad Shaneh
Eugene Sandulenko
Matthew Duggan
Timo Mikkolainen
Mataniko
Walter Agazzi
Martin Gerhardy
D G Turner
Paul Gilbert
Paweł Kołodziejski
ScummVM-Translations
Cameron Cawley
Lothar Serra Mari