Making it hardcoded because:
* This is the only place where it could happen
* It is the second time in history of ScummVM when we renamed
and engine (the first one was Simon -> AGOS)
Thus, there is a little sense in creating a universal solution.
- Changed so we can get any type of plugins.
- This used to always return PLUGIN_TYPE_ENGINE.
- Because now we can differentiate between engines and metaengine, this must be changed.
- For now, return METAENGINE by default
- Do NOT use pluginMan and load plugins, etc, etc.
- Get MetaEngines from memory, since they're always built in statically.
- Use detectGames method to detect games.
- MetaEngines will now always go to the executable.
- But, because they still live in engine projects and are connected via a macro, they will need to be differentiated from Engines.
- This macro, and it's use in future will help in that.
Currently, the plugin architecture searches for plugins in ScummVM's
base directory and in the plugins directory itself.
However, for Win32, we need to bundle several DLL files in order to
make ScummVM run at all. Currently, this leads to several warning
messages since ScummVM tries to load those DLLs as plugins.
This patch excludes the ScummVM base directory when running on Win32 and
only accepts plugins from the plugins directory.
CoreMIDI provides hardware midi device support.
On my MacBook, the first call to MIDIGetNumberOfDestinations() takes around 2
seconds. Using one of the midi devices lower on the plugin list (mt32,
fluidsynth, etc) takes 2 extra seconds on every game start as
MidiDriver::getDeviceHandle() enumerates all the plugins to find the right one.
This change simply moves CoreMIDI to the bottom of the list. It will still
take 2 extra seconds when opening the options box, but that's a rare operation
relative to starting games.
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: e2d91258b7
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.
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 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.
