| Age | Commit message (Collapse) | Author |
|---|
|
These are flagged by GCC if -Wswitch-default is enabled.
|
|
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.
|
|
Initializing Common::RandomSource's seed with a fixed value will always
yield the same sequence of pseudo-random numbers which is probably not
desirable. Since the constructor takes care of initializing the seed
properly doing so manually is not needed.
|
|
Fix undefined behaviour in variadic functions
|
|
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
|
|
Passing a type that undergoes default argument promotion as last
argument of a variadic function results in undefined behaviour.
|
|
All these fall through were marked as deliberate, so again I've only
changed the comment to silence GCC.
|
|
|
|
The engine data files should be included in the package, so downloading
may not be the best suggestion. Instead refer to the README.
|
|
|
|
|
|
|
|
Recently we started to use this as new semantics, although in the past
we used simly <engine>_H. Now these guard defines are consistent with
rest of the files which are used in the engines.
|
|
|
|
|
|
gameid -> gameId
guioptions -> guiOptions
|
|
|
|
|
|
|
|
|
|
When drawing cursor text, don't draw it above the top of the screen,
since this would lead to memory corruption and crashes. I'm not quite
sure this is all of bug #6799 since it also mentioned that "sometimes
simply using a hotspot will be enough", but it's a start.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.
|
|
This is now generated automatically by the configure script from the
engine directory names.
|
|
This is the third and final commit enabling fully pluggable engines.
Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.
|
|
This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.
|
|
This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"PC" was very ambiguous and now it matches what we show in the GUI.
This also corrects sword2's platform to Windows.
|
|
|
|
|
|
|
|
|
|
This is done in the spirit of 658080deeda79d20ea40643569fbcb072573e7cf.
|
|
This is according to wjp's suggestion - the pitch didn't make sense there
|
|
|
|
|
