Difference between revisions of "TODO"

TODO (view source)

Revision as of 08:29, 8 April 2006

718 bytes removed , 08:29, 8 April 2006

Removed some obsolete TODOs

Fingolfin

1,079

edits

@@ Line 131: / Line 131: @@
 === Plugins ===
-* Add a plugin API that allows querying a plugin for the savegames associated with a given game; that is, you pass the name of a target from the config to the plugin, and it returns a list of savegames. How that list would look like exactly is debatable; but it should be possible to extract a user friendly name; a slot ID corresponding to the "-x" command line param; and possibly a filename. Justification: This API would make it possible to directly load savegames from the launcher.
+* Add a plugin API that allows querying a plugin for the savegames associated with a given game; that is, you pass the name of a target from the config to the plugin, and it returns a list of savegames. How that list would look like exactly is debatable; but it should be possible to extract a user friendly name; a slot ID corresponding to the "-x" command line param; and possibly a filename. Justification: This API would make it possible to directly load savegames from the launcher.<br>This savegame API could return additional (optional) information for each savegame entry: name; creation date; thumbnail screenshot
-* This savegame API could return additional (optional) information for each savegame entry: name; creation date; thumbnail screenshot
-* When building with the fake static plugins: instead of hardcoding the list of plugins, plugins should automatically be "hooked in". This can be achieved by modifying REGISTER_PLUGIN to insert special code into the plugins. UPDATE: I tried this, but it doesn't really work due to constraints imposed by the way most C++ compilers/linkers out there realize global constructors.
 * On OSX: Support a plugin build in the bundle target: *.plugin files should be put into ScummVM.app/Contents/PlugIns/; this also means that the loader needs to search in the plugin dir of the active bundle. So use the CF bundle API, inside a #ifdef MACOSX block.
 * When creating an engine instance, there is currently no way for the plugin to indicate an error, except for returning a NULL value. It would be nice if the engine could specify why creating the engine instance failed (e.g. due to lack of memory, because a file couldn't be found, because the game was not recognized, etc.).
-* Currently, there is only a single list of game IDs return by each engine. That list is both used to detect which engine handles a given user target, and to display a list of supported game IDs. This leads to "-z" displaying e.g. the obsolete "zakTowns" target. So we should separate the two. There are multiple ways to do that, of course.
 * Split base/plugins.h into the part needed to implement a plugin, and the part needed by client code. Maybe also move DetectedGame and GameSettings to a new file base/game.h
 * Replace DetectedGame by a 'map' containing essentially the same data that the config file would contain -- i.e. gameid, description, language, platform; but also any further data, like e.g. basename, target_md5, or *anything* the engine deems important. -> far more flexible, and helps to simplify the launcher code, too.