Age | Commit message (Collapse) | Author |
|
When the plugin-engine mapping is not cached in the configuration file,
we were not scanning all the plugins to establish the mapping.
This is a regression from commit: e2d91258b7bfb989dc099f516bb31ceb44554529
This commit reverts the offending commit and implements a proper fix for
the case where there are no dynamic plugins.
Fixes #11300.
|
|
|
|
|
|
Qualified game names have the following form: engineId:gameId.
Unqualified game names are still supported as long as they are not
ambiguous. However they are considered deprecated and are no longer
displayed by the --list-games command.
|
|
|
|
The engine ID identifies which engine should be used to launch the target.
Also remove the 'single ID' system. Different games from engines that used
that system now have different game IDs.
Also-By: Matthew Hoops <clone2727@gmail.com>
|
|
* The list of candidates now includes unknown variants. When an unknown
variant is selected, the unknown game dialog is shown.
* On the unknown game dialog, users are given the choice to add the game
when that is possible, or to cancel.
The goal of those changes is to make the unknown game dialog less
confusing for users, especially when both known and unknown games
variants are found.
|
|
The other plugins do not need to be reloaded. Reloading
the scaler plugins breaks the graphics.
|
|
|
|
Was introduced in the recent detection rework.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the Add Game feature
|
|
|
|
Previously, a C-style cast was used to convert a
Common::Array<Plugin *>, populated with pointers to StaticPlugin
and DynamicPlugin instances, to a
Common::Array<PluginSubclass<T> *>, but PluginSubclass<T> is a
*sibling* class to StaticPlugin/DynamicPlugin, so this cast was
invalid and the results undefined. The methods for retrieving
subclasses of plugins can't be easily changed to just generate an
array of temporary wrapper objects that expose an identical API
which dereferences to the preferred PluginObject subclass because
pointers to these objects are retained by other parts of ScummVM,
so the wrappers would needed to be persisted or they would need to
just re-expose the underlying Plugin object again. This indicated
that a way to solve this problem is to have the callers receive
Plugin objects and get the PluginObject from the Plugin by
explicitly stating their desired type, in a similar manner to
std::get(std::variant), so that the pattern used by this patch to
solve the problem.
Closes gh-1051.
|
|
This reverts commit eefa72afa1978a9dea10f5b1833fcc8f58a3468e.
With this patch ConfigManager is broken.
|
|
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
|
|
|
|
|
|
New sndio MIDI backend for OpenBSD written by Alexandre Ratchov.
Tested with an external MT-32 and fluidsynth.
|
|
The new header engines/plugins_table.h is currently manually created
and maintained, but could be regenerated by a script in the future.
|
|
Thanks to Yotam for confirming that this isn't needed anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Silences the clang warning:
static data member specialization of '_singleton' must
originally be declared in namespace 'Common'; accepted as a C++0x
extension [-Wc++0x-extensions]
Wrapping "namespace Common {}" around the macro assignment causes clang
to complain about a spurious semicolon, and removing the semicolon at
the end of the macro causes some editors to misbehave.
Changing the requirement of using the macro in one namespace (the
global) to another (Common) seems a small price to pay to
silence a warning.
|
|
|
|
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
|
|
|
|
|
|
|
|
|
|
|
|
Based on the SONiVOX® Embedded Audio Synthesis (EAS™) library, which is
part of the base Android OS.
CPU stats (Cortex A8 1GHz, monkey1 intro, peak values):
MAME OPL: 30%
DosBox OPL: 26%
EAS: 19%
|
|
|
|
svn-id: r55850
|
|
elsewhere
There are some calls to EngineManager::findGame() from within games, such as when loading saved games. It's critical not to unload the plugin from memory or other threads may crash. Therefore, we first scan using any plugin that's already in memory.
svn-id: r55089
|
|
ONE_PLUGIN_AT_A_TIME is too long.
svn-id: r55064
|
|
svn-id: r55062
|
|
After searching for the right plugin once, the filename will be saved to the config file under the domain 'plugin_files'. The key is the gameid and the value is the plugin file. The backup mechanism is searching plugin by plugin.
svn-id: r55061
|
|
The reason for this was that I found issues where the wrong functions were called in EngineManager for single plugin operation. Rather than inserting more messy #defines, I preferred to change the PluginManager to use virtual functions, which also makes EngineManager simpler.
svn-id: r55024
|