The original has 2 ways to start a new game:
1. start from dos -> intro movies -> difficulty menu -> voice mail movie
-> game
2. playing game (press esc) -> game menu (new game) -> difficulty menu
-> voice mail movie -> game
We now match those sequences correctly.
There is one difference still - if you have a saved game, we will by default
load that. Previously the game jumped straight into that, but since there is
now no other way to see the intro movies again, now they are always shown
first. So the 3rd flow is (if you have a save game):
3. start scummvm -> intro movies -> game
Since some people might want to just jump straight into the game, I also added
a skip_intro config file setting which will skip the movies in this case.
Fixes#12758.
Now that we can get an accurate HiDPI screen scaling from OSystem,
defaulting to using that seems to make sense. But we may still want
to use a slightly different scaling. The GUI scale option allows
that by providing a scaling (in percentage) with which to multiply
the HiDPI scaling.
I think it works better than a base resolution as it avoids having
the GUI getting bigger or smaller when we resize the window.
This commit keeps a popup widget, but this could be changed with
a slider if we want more fine grain control.
This is a placeholder implementation that preserves the current
behaviour (asusmes a scaling of 2). But since the Android API
provides a way to get an accurare device-dependent scaling, this
should probably be used.
The pathfinding debugging code is using Sierra's buggy 8-bit matching
algorithm to find colors for drawing obstacles and path points in most
of the SCI 1.1 games. This usually results all colors being black.
Now we select the good 16-bit algorithm for internal use.
Fixes crash when kDebugLevelAvoidPath is enabled and kMergePoly merges
room obstacles, such in QFG1VGA after defeating a monster.
The debugging code that draws obstacles uses the polygon type as an
index to a color array and asserts that this value is between 0 and 3,
but that didn't take into account the 0x10 flag that kMergePoly sets.
In backends/fs/windows/windows-fs.cpp, the macros F_OK/R_OK/W_OK are not defined by system includes of MSVC, so they have been added manually into the code.
While this solution works, in my opinion it would be much cleaner to use GetFileAttributes() for getting this information.
Actually, this is what the _access()/_waccess() functions do and, afterall, this is a piece of code expected to work on Windows only.
