| Age | Commit message (Collapse) | Author |
|---|
|
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
|
|
MSVC complained about a potentially uninitialized variable here
|
|
Also-By: Matthew Hoops <clone2727@gmail.com>
|
|
This fixes bug #10398 ("FULLPIPE: memory leak when exiting via in-game
menu (not gmm)").
|
|
Swapped out the #define ANGLE(X) function that did degrees
to radians.
I have made everything doubles in the angle calculation.
|
|
The previous URI spawns many useless subshells on the POSIX backend
through (harmless) shell command injection.
|
|
|
|
Remove duplicate headers in two files and ordered
the headers similar to other fullpipe files.
|
|
|
|
This commit introduces the following changes:
1. Graphics::loadThumbnail()
Now returns a boolean and takes a new argument skipThumbnail which
defaults to false. In case of true, loadThumbnail() reads past the
thumbnail data in the input stream instead of actually loading the
thumbnail. This simplifies savegame handling where, up until now,
many engines always read the whole savegame metadata (including
the thumbnail) and then threw away the thumbnail when not needed
(which is in almost all cases, the most common exception being
MetaEngine::querySaveMetaInfos() which is responsible for loading
savegame metadata for displaying it in the GUI launcher.
2. readSavegameHeader()
Engines which already implement such a method (name varies) now take
a new argument skipThumbnail (default: true) which is passed
through to loadThumbnail(). This means that the default case for
readSavegameHeader() is now _not_ loading the thumbnail from a
savegame and just reading past it. In those cases, e.g.
querySaveMetaInfos(), where we actually are interested in loading
the thumbnail readSavegameHeader() needs to explicitely be called
with skipThumbnail == false.
Engines whose readSavegameHeader() (name varies) already takes an
argument loadThumbnail have been adapted to have a similar
prototype and semantics.
I.e. readSaveHeader(in, loadThumbnail, header) now is
readSaveHeader(in, header, skipThumbnail).
3. Error handling
Engines which previously did not check the return value of
readSavegameHeader() (name varies) now do so ensuring that possibly
broken savegames (be it a broken thumbnail or something else) don't
make it into the GUI launcher list in the first place.
|
|
|
|
Scene 22 now doesn't freeze when pulling lever with stool under it
|
|
Fixes Trac#10394.
|
|
This is a tad more meaningful than a random value, especially should we
for some reason use dummy header information to actually set playtime in
the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
screen
|
|
|
|
|
|
|
|
abe1c65d626a8f3 changed _trackName from a char * to a Common::String,
but still tried to access the null terminator byte.
|
|
cce851d1af introduced a check to allow only static ani objects. However
after this change, only part of the pipes for vertical movement were
interactive.
This change aims to restore functionality for the other object types
while still preventing the invalid casts.
|
|
Fixes #10322.
|
|
In C++ the function parameter evaluation order is undefined. The count
property was being read first from the stream, instead of the itemId.
Fixes #10324.
|
|
|
|
Fixes Trac#9657.
|
|
|
|
Pointers to objects which are invalidated when the scene gets
unloaded may continue to be accessed if a mouse hover event is
dispatched to the ModalMainMenu.
|
|
|
|
|
|
Nearly every construction of an ExCommand in the engine sets flag
2 of _excFlags. It may even be that the remaining ones that don't
are themselves bugs. This flag is needed in order for an ExCommand
to be cleaned up when its parent MessageQueue is deleted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I am not entirely sure this is a correct fix for these leaks;
there is still the issue of the last member of _dynamicPhases being
invalidated and not removed sometime before the destruction of
Movement. Also, some of the items in this array are not actually
owned by Movement so deleting them will cause double-frees or
use-after-frees. It may be the case that a second list should be
maintained instead containing only the objects that are created
internally within Movement. Further testing will tell for sure.
|
|
|
|
|
|
|
|
|
|
|
|
|
