Age | Commit message (Collapse) | Author |
|
|
|
Currently translated at 100.0% (965 of 965 strings)
|
|
|
|
The README and command line help indicated this should work,
but this was not implemented.
|
|
|
|
|
|
|
|
|
|
New semantics is as follows:
[-p <dir>] --add adds all games in <dir> or
working dir
[-p <dir>] --detect enumerates dectected games in
<dir> with their ids
[-p <dir>] --game <id> --add adds just game <id> if found
in <dir> and not already added
[-p <dir>] --recursive --add adds all games in <dir> and
subdirs if not already added
[-p <dir>] --recursive --game <id> --add
adds just game <id> if found
in <dir> or its subdirs and
not already added
[-p <dir>] --recursive --detect enumerates games in <dir>
and subdirs
[-p <dir>] --auto-detect launches the first game
found in <dir>
[-p <dir>] --recursive --auto-detect
displays error message
The reason for the displaying an error message when attempting to do
autodetection on a whole tree is mainly one of UX, IMO it *might* get
confusing on a sufficiently large/deep tree.
The relevant if() can be removed safely if it's concluded that's not the
case.
|
|
This implements the behaviour as discussed in PR926:
https://github.com/scummvm/scummvm/pull/926#discussion_r126132411
Essentially:
[-p <dir>] --add adds all games in <dir> or working dir
[-p <dir>] --detect enumerates dectected games with their
ids
[-p <dir>] --game <id> --add adds just game <id>
|
|
Use snprintf() instead of sprintf() to limit how much is written
to the buffer. Note that there are other places where it looks
like it could overflow, but they did not trigger warnings and I'm
guessing that it doesn't overflow in reality.
|
|
Currently translated at 100.0% (965 of 965 strings)
|
|
|
|
This also moves logic for detecting which movement is associated
with given keycodes and cursors to CMovementMsg and CLinkItem,
which are better suited to contain the logic
|
|
Comments explain how the num lock handling works before the
fall-through cases.
|
|
|
|
|
|
I think these are the last one that were already flagged as being
deliberate.
|
|
|
|
|
|
Probably doesn't ever happen, but now 'fileName' is as large as it
needs to be if 'label' is as long as it can be.
|
|
|
|
These weren't explicitly flagged as deliberate, but I recognize
Duff's Device when I see it.
|
|
All these fall through were marked as deliberate, so again I've only
changed the comment to silence GCC.
|
|
|
|
The Steam version is a DVD version, but also has files from the CD
version in the data folder. We need to load only the files from the DVD
version to prevent data inconsistencies.
Also check on startup that all the required datafiles are present.
Possibly fixes #10052.
|
|
Though since I don't have the game I can't actually test it. :-)
|
|
There were all flagged as intentional fall throughs. I simply changed
the comments to something GCC would recognize.
|
|
Caught by GCC 7 (though the warning seemed misleading to me). Since
SoundDesc->name can potentially be 14 characters "%s_reg%03d.fla"
can be 25 characters, plus the terminating \0.
|
|
Since case 64 was added for "MM C64 Costume Animation", and
considering the way it's written to only affect game version 0,
it is clearly an intentional fall through.
|
|
We have lots and lots of -Wimplicit-fallthrough warnings, and I
don't know if it's worth fixing them or not. But if we want to,
this is how it can be done.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The fix deals with a bug in the original that if an item was used
that the drop target didn't handle, the item wouldn't be returned
to the player's inventory
|
|
|
|
|
|
|
|
|
|
Fixes #10063.
|
|
|
|
Those are obviously repackaged CD versions
|
|
|
|
Previously we were clearing the whole backbuffer for 3 frames after a
window size change, and then only clearing the game area. This assumes
the OpenGL driver uses at most 3 render buffer and uses them in
sequential order. This does not seem to be the case on Linux when using
an Intel integrated GPU.
Instead we now clear the whole backbuffer on each frame to make sure
there are no leftovers remaining on the screen. All semi-recent GPUs
should have hardware clear anyway so this should not impact negatively
performance.
Possibly fixes #10025.
|