Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
Futile attempt at taming the mess. There is also much leftover
unused code which someone who knows what all of this does should
remove, if possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The original didn't allow loading during combat from it's
options dialog, and I'll leave that untouched, but the ability
to load out of a unwinnable combat is too convenient to not
allow in some form.
|
|
|
|
|
|
|
|
I still haven't tracked down how the original handles the
integer division rounding that results in the pre and post
deposit Deposit dialog message being offset by 1 pixel.
But since the problem could be resolved by standardising
when center alignment is set in both messages, and I
haven't noticed any problem elsewhere, I think this is
sufficient for now
|
|
|
|
This allows the well open door/gate, shoot at enemies, then close
to work with the mouse as well as the keyboard. The pending event
queue has also been limited to 5 pending events. Trust me, you
don't want to spent time spamming Shoot at a high level monster
that can't reach you, only for when it's killed to have to wait
several minutes whilst your party keeps shooting.
|
|
|
|
|
|
They are identical to those detected by configure on buildbot
|
|
|
|
|
|
No sense in deleting and then allocating an object again because loadStream method destroy previous data.
|
|
destructor of Common::File anyway calls close method
|
|
|
|
delete perfoms the check anyway
|
|
|
|
Starship Titanic produces lots of "uninitialized value" warnings
at the very beginning of the game, when turning right. This is
because in the very first movie frame it uses codebooks that have
not been loaded. Explicitly set their data to 0 to guarantee
consistent behavior.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
This avoids a problem where holding down Ctrl for the GMM
was passing multiple turns.. very noticeable if there were
monsters nearby, or the party is standing on a trap tile
|
|
|