Moved the TODO to the Wiki

svn-id: r21647

1 files changed, 0 insertions, 466 deletions

diff --git a/TODO b/TODO
deleted file mode 100644
index 9c4ff6fb59..0000000000
--- a/TODO
+++ /dev/null
@@ -1,466 +0,0 @@
-Here is a list of things we plan to do in the future. Note that we
-don't promise to do any of these, nor when we will do them. It's just a
-list of what we hope to be able to do one day.
-
-If you want to dig in, this is the stuff where you might make the most
-useful contribution. Note that this list is never complete, and may be
-partially outdated, so just because you don't see something here doesn't
-mean it is not important.
-
-Before you start work on something, you should first talk to the team!
-Ideally ask on scummvm-devel, our mailing list. This will help us to
-prevent double work, i.e. several people working on the same stuff at
-once without knowing about each other. Furthermore, sometimes entries
-on our list are actually obsolete (because the feature has been
-implemented, or because for some reason we no longer think it to be
-desirable). Special caution should be taken for TODO entries that say
-"we may want to" or similar things; that usually means that we aren't
-sure whether we really want to implement that feature.
-
-So, to repeat it: Always talk to the team before implementing a change
-on this list, or else risk having your patch rejected :-/.
-
-Finally, always make sure to check out our bug tracker and our feature
-request tracker for things that need work.
-
-
-#######################################################################
-# Docs, Web site
-#######################################################################
-
-General
-========
-* Add port specific user documentation (dreamcast/palm especially). That
-  would include things like:
-  - How to use ScummVM on system XYZ
-  - Which Palm / WinCE devices will run ScummVM, which definitely will not
-    run it (or with which limitations)?
-* Update/enhance man page
-* Write a high level overview of how ScummVM and its engines work?
-
-README / Manual
-===============
-* Ender is working on a new multi-format manual/readme.
-  Since so far we haven't seen anything of that, Fingolfin has started a
-  DocBook based manual (and FAQ, and Developer's Guide). You can find it in
-  the CVS module "docs".
-  Finally, there is a LaTeX based version of the README in the "doc" subdir
-  of the "scummvm" CVS module, but it tends to slip out of sync with the
-  plain text README, and it's not really a manual, it's just the README
-  in a different file format.
-* Everybody is welcome to start helping out with the public manual project
-  in the "docs" CVS module. You can either reuse content from the README,
-  or replace it with new, better written stuff. Contact Fingolfin or our
-  mailing list, scummvm-devel, if you are interested in helping out.
-* It would be greate to have a "Developer's Guide to ScummVM" which explains
-  the ScummVM framework, and also the engines, i.e.
-  - stuff in common/, like the config manager etc.
-  - the backend API, and how to create new backends
-  - the sound system
-  - how to create a new engine
-  - a chapter for each engine, with as many/little details as the resp.
-    engine teams deem appropriate...
-  - ...
-
-LaTeX docs
-==========
-* These are constantly out of sync with the README :-/
-* The files are currently named in a very dumb fashion -- using their section
-  IDs, which of course constantly change. Better would be to give them names
-  based on their content instead. E.g. create a subdir for each chapter,
-  move the (sub)section files into that directory and rename them to match 
-  their content, instead of their section number (which changes all the time).
-  -> Fingolfin would do it, but wants to wait until the SVN switch.
-
-
-Code
-====
-* Add more Doxygen comments. However, quality is preferable over quantity
-* Document the OSystem overlay API, it badly needs it...
-
-Web site
-========
-* Add the "Manual" / README to the site
-
-#######################################################################
-# Common code, infrastructure
-#######################################################################
-
-General
-=======
-* Revise the way "quit" is handled. Maybe add a global variable "g_quit" which
-  we set when the application should be quit (e.g. when an EVENT_QUIT is
-  received). This is useful if multiple levels of event loops have to be ended
-* Fix the Map<> template, make it more robust; maybe use a red-black tree?
-* Make some generic "EventLoop" API/class which all backends and the GUI
-  use. Initially this would just call the backend poll_event() etc. methods.
-  But eventually the EventLoop object(s) could be made by the backend.
-  This may allow for more efficient CPU usage etc.
-  The current event handling model essentially is polling: the engines run
-  some kind of main loop, which, besides many other things, also polls and
-  dispatches events. The idea is to turn this around: the event loop
-  frequently gives the engine time to do these "other things".
-* Make the autosave interval configurable (via GUI, command line, config file).
-* Maybe add ways to modify the game configs via the command line. E.g. allow
-    ./scummvm --add new_target --path=/foo monkey2
-    ./scummvm --remove new_target
-* Maybe allow launching games even if no target is specified? I.e. the user
-  only has to specify a path (or run ScummVM from the right directory), and
-  ScummVM auto-detects the game in that location
-    ./scummvm --auto-detect
-  Of course, if we do it, it has to be done so that the launcher is still
-  reachable :-)
-* Some source files should be moved. But that's a pain with CVS, so let's
-  wait until we switch to something better, like Subversion. In particular:
-  - consider moving the MIDI stuff from sound/ to sound/midi/ 
-  - move fmopl code to softsynth dir
-  - maybe common/system.h / system.cpp should go to backends/, too ?
-* The following things should be put into namespaces:
-  - AudioStream and subclasses into Audio
-  - MIDI related classes either to Audio, or a new "MIDI" namespace
-  - backend specific stuff into ??? (maybe new namespace "Backends" ?)
-    not sure about this one.
-
-
-Build System
-============
-* Add test(s) for backend usability in the configure script.
-* Enhance the Makefile-based build system to support VPATH and stuff, so that
-  one can compile scummvm in a directory tree separate from the source tree.
-  That would make it possible to build ScummVM with different build options,
-  e.g. have one debug build and one optimized build.
-  Fingolfin implemented most of this; the only thing missing is that configure
-  should detect when it is run in a directory outside the source tree, and in
-  that case generate a custom Makefile, with content like this:
-	srcdir = /path/to/source/dir
-	vpath %.cpp $(srcdir)
-	vpath %.h $(srcdir)
-	include $(srcdir)/Makefile
-* Allow automatic re-runs of configure (this would have to 'save' the values of
-  env vars like CXXFLAGS and also command line params)
-* Add an install target to the Makefile - Copy binary, install manpage, add
-  menu items, install README. See also patch #891909 (Gnome/KDE .desktop file)
-
-Audio
-=====
-* Get the high quality resample code to work
-   [Fingolfin has started work on this]
-* Consider changing the mixer volume to use range 0-255, for sake of
-  consistency (but at a slight loss of efficiency). Note that this requires
-  changes in at least rate.cpp and mixer.cpp.
-* MIDI: Add API to OSystem which allows client code to query for "native"
-  MIDI drivers (like Windows, ALSA, Zodiac, CoreAudio). Then change the
-  MIDI interfacing code (GUI, command line, config file, etc.) and also
-  MidiDriver::createMidi() to use both that list and the list of
-  'emulated' MIDI devices (Adlib, MT-32, PC Speaker, etc.) in an appropriate
-  way.
-* The Audio CD Manager, and especially the DigitalTrackInfo class could
-  stand an overhaul. The system currently is not as easy to extend as one would
-  wish. In particular, it would be nice if arbitrary AudioStream classes could
-  be used here (this then would reduce code duplication and make it instantly
-  possible to use WAV/VOC encoded audio tracks, should we desire to support
-  those).
-* Modify our audio stream classes (for MP3/Vorbis/FLAC/... playback) to use
-  SeekableReadStream instead of Files -> allow from-memory-playback.
-  And could take advantage of a new hypothetical "Sub(Seekable)Stream" class.
-  (See below for more info on that).
-
-Config Manager
-==============
-* Add a 'notification' system. E.g. the SoundMixer could request to be notified
-  whenever the value of the "volume" config option changes. In other words,
-  instead of a "pull" approach (where each subsystem has to check whether any
-  config option relevant to it has been changed) we use a "push" approach.
-  Of course the current approach is "push", too: whenever e.g. the volume
-  setting is changed, the code doing so has to updated the SoundMixer etc.
-  That's cumbersome, and error prone. Would be much nicer if updating the
-  volume config value automatically notifies the SoundMixer, iMuse etc.
-* Modify the ConfigManager to make use of the ConfigFile class.
-* Maybe even follow the pentagram (http://pentragram.sf.net) approach and have
-  three classes:
-  - SettingsManager (like our current ConfigManager)
-  - ConfigFileManager (manages a set of config files, possibly merging the data
-    from multiple config files)
-  - ConfigFile (a simple .ini file accessor).
-  This makes it easy to add additional config sources (e.g. XMLConfigFile);
-  makes it possible to treat the command line data like another config file
-  (CommandLineConfig); and simply follows the good old MVC approach, which
-  is always a good idea.
-
-Files
-=====
-* Add a FilesystemManager or FileManager or so which should unify and/or
-  replace the current File/FilesystemNode classes (and maybe SaveFileManager).
-  The goal is to make these things as portable as possible while keeping it
-  easy to use for the coder. Some new functionality we need:
-  - check for existence of file/directory
-  - check whether given directory is readable/writeable
-  - convert FSNode into a string representation (for prefs file)
-  - convert said string representation back to FSNode
-  Of course that can be added w/o a FileManager class, too - but it might be
-  nice to have all of these integrated.
-* Get rid of the incRef/decRef API of class File. Instead, add a clone() method
-  which generates a new (independant) File object for the same file (only would
-  work for files in read mode, obviously). Convert the audio code to use this
-  instead of the ref counting.
-  Reason: Using a shared file object can lead to race conditions if multiple
-  threads try to use it at the same time; on some systems (Symbian) it is 
-  apparently not even possible to do it; iahd t can also cause problems even in
-  non-threaded code, when we seek in one block of code, and then try to access it
-  from another block, w/o reseeking first.
-
-GUI
-===
-* Remove hard coded 320x200 assumptions, use game screen size. In particular,
-  all the dialogs should be rewritten to allow for that. At this point, most
-  (all?) dialogs are able to scale themselves, but the way they do so is
-  sometimes a bit hackish, the layout could be improved, and there are glitches
-  with the small version of the GUI.
-* EditableWidget: Make it possible to specify a min/max length for the text
-* EditableWidget: Let setEditString filter the string it gets
-* EditableWidget: Right now, custom filtering requires the user to subclass;
-  it would be nice if there was simply a "validator hook" or so.
-  Maybe take some inspiration from Java's Swing in this matter.
-* Improve EditTextWidget::drawCaret and ListWidget::drawCaret support for
-  alternate fonts (the current code overdraws chars partly, and relies on the
-  fact that our default built-in font has a separation pixel column on the
-  *left* side; most other bitmap fonts have it on the right, though). To this
-  end, we maybe should backup the background before drawing the caret, and
-  restore it when erasing the caret.
-* PopUpDialog: Must be able to handle longer lists (by adding scrolling?). The
-  language popup currently doesn't fit in the small version of the GUI.
-* Add a new "options" dialog which is used by all frontends: for this, we'd
-  agree on a hotkey used in all engines to invoke that dialog; it would sport
-  settings for the volume, graphics, paths, etc.; it would co-exist with the
-  engines "native" option dialogs.
-  The about dialog would be reachable from here, too, as well as a quit button.
-  Justification: This ensures that all settings are really reachable from
-  all of the engines, which is not the case currently.
-  Problem: It's not fully clear to me how to "best" deal with global vs. local
-  settings here...
-* Maybe add the ScummVM logo (+typeface?) to the about dialog
-* There is currently no way to unset the SoundFont from the GUI, if any was
-  set. Maybe add a 'clear' button for it? The same holds for other path
-  settings.
-* ScrollBarWidget: Add auto-repeat: if user clicks & holds on one of the
-  arrows, then after a brief delay, it should start to contiously scroll.
-* AboutDialog: Add a "fade" effect for the top/bottom text lines
-* AboutDialog: Maybe prerender all of the text into another surface, and then
-  simply compose that over the screen surface in the right way.
-
-
-Graphics
-========
-* Add some more fonts/font variants? Maybe a tool like ttf2bdf could be used
-  to convert on (free!) TTF font to both a small and a big font for the GUI,
-  maybe including bold/italic variants
-* Allow loading external fonts (BDF format?). Useful for GUI customization.
-* Use 'complete' fonts, encoding wise. In particular, we should probably pick
-  one encoding (e.g. ISO Latin 1) and standardize on it. Oh yeah, a map from
-  the SCUMM  encoding to that encoding would be useful.
-  That way, we can at least all systems/languages which use that encoding.
-  Of course, kyrillic and asian users, amongst others, wouldn't be helped
-  by this, but there is nothing we can do for them anyway, short of
-  implementing an UTF8 based font rendering engine. (And no, there is no way
-  we are going to do such an absurd thing. Better to implement native GUIs
-  than to write our own OS :-).
-* Consider implementing a new internal font format which
-  - takes up less space in the executable (ascii vs. binary encoding)
-  - allows for multi-color/anti-aliased fonts
-
-Launcher
-========
-* Add more options to global options dialog
-* Add more options to game target options dialog 
-
-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.
-* 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.
-
-
-OSystem
-=======
-* Right now gBitFormat is part of common/scaler.cpp; we might want to move it
-  to common/system.cpp, or replace it with something better.
-  No hasty changes here, please, make sure you understand how it is used right
-  now before messing with it ;-)
-* Document key codes to be used for special keys, like F1-F15 etc.
-
-Streams
-=======
-* Add a Sub(Seekable)Stream wrapper class: You pass a (Seekable)Stream,
-  an offset and a size to it. It will pass all calls on to the wrapped
-  stream, but will restrict access to the specified byte range.
-  This then can be used in various places, e.g. in many of the AudioStream
-  classes, to simplify code.
-* Add a "clone" method that makes a copy of the (seekable/readable) stream.
-  In the case of files, this would create a new file descriptor.
-  Purpose: Replace the Symbian hack in MP3InputStream and other places;
-  in particular, often we need two parts of code to access the same file
-  but in separate positions...
-
-#######################################################################
-# Engines / frontends
-#######################################################################
-
-General
-=======
-* Fix engines so they clean up after themselves, to allow proper re-entry
-  to the launcher. See "FIXME: LAUNCHERHACK" in base/main.cpp
-* Get rid of GF_DEFAULT_TO_1X_SCALER and the 'defaultTo1XScaler' parameter of
-  Engine::initCommonGFX. They form a crude hack to better support 640x480 games
-  and are meant to prevent those games from being accidentally scaled to a size
-  that won't fit on the screen. However, the proper fix would be to modify the
-  backends so that they simply fall back to a smaller scaler when a combination
-  is requested that can't be satisfied.
-
-SCUMM
-=====
-* Make it possible to restart games properly
-* Add method of setting initial debug channels from command-line
-* Possibly implement a new resource manager, which then also could be shared
-  by ScummEX. [Jamieson has some ideas about this].
-* Figure out how to extract resources from Apple II versions
-* Figure out how to extract resources from Turbografx/PC Engine version of Loom
-* Loom EGA: Add support for music and sound effects in Macintosh version
-* Add support for handling Kanji in FM-Towns games (foreground is rendered on a
-  second plane at 640x480), text uses Shift_JIS encoding
-  [implementation now that currently depends on font rom, not needing the rom
-   would be preferable]
-* Add support for TFMX music format in Amiga version of Monkey Island 1
-  Check http://darkstar.tabu.uni-bonn.de/~neo/audio.html for music format
-  details
-* When SMUSH movies end, their music track sometimes should last a bit longer;
-  currently, we stop the audio together with the animation, leading to cut off
-  music.
-* Clean up class Gdi. This class right now mostly is about decoding various
-  graphic formats. However some other functionality has crept into it, too.
-  It would be nice if class Gdi would only contain the GFX decoding code, and
-  nothing else (assuming that is feasible w/o too much trouble).
-  OTOH, the code which is responsible for managing virtual screens, rendering
-  virtual screens to the real display etc. could be grouped into a new class
-  (e.g. VSManager or so).
-
-Broken Sword 2
-==============
-* Enforce ScummVM code formatting guidelines. (Mostly done?)
-* Encapsulate the code into sensible objects. (Partly done.)
-* Enable the CD swapping code. (Partly done.)
-* Fix the credits so they look more like the original. (Did we ever get the
-  source code for that?)
-* Maybe work around script bug which causes the mop to disappear briefly when
-  trying to pick it up from the top of the boat at the London docks. (The event
-  to hide the mop is sent too early.) See bug #1214168.
-* Unify some of the code with Broken Sword 1 (e.g. in router.cpp).
-
-#######################################################################
-# Backends
-#######################################################################
-
-General
-=======
-* Several of the backend factory functions take config parameters. It should
-  be possible to get rid of those once the config system rewrite (see above)
-  has been done. In that case, the backends simply can query the config
-  manager for these parameters (or any others they might like :-).
-* Change backends to directly access the config manager
-* Add API to query backend for a list of available music engines
-  Useful for Options dialog
-* MS DOS port using Allegro <http://www.talula.demon.co.uk/allegro/> and
-  DJGPP <http://www.delorie.com/djgpp/> ?
-* Intent <http://withintent.biz/> port (already done by David Given, merge?)
-* Digita OS port? (play games on a select few digital cameras...)
-  <http://digita.mame.net/reviews.htm>
-
-X11 backend
-===========
-* Add frills used by SDL backend like graphic filters usage and CD audio
-
-SDL backend
-===========
-* Right now, the WinCE backend subclasses the regular SDL backend. The
-  Symbian backend will do that, too (it is not yet in CVS, though).
-  They both overload a lot of methods (mostly the graphics stuff). Since
-  graphics.cpp uses the scalers (e.g. hq3x), these derived backends
-  carry that baggage around, too, even though they don't need that code.
-  Idea: split the SDL backend into two classes, one base class which only
-  has the code which is used by all subclasses; and a "desktop" subclass,
-  which implements the rest. Then WinCE/Symbian would only subclass the
-  "base" SDL class.
-* We implemented GFX transactions & commits some time ago -- but they are only
-  half the story. We are still missing a rollback system -- that is, check
-  whether the requested video mode works, if it doesn't, revert to the current
-  settings -- at least "if it makes sense". That is, if the transaction
-  only modified the scaler or aspect ratio, we can safely revert. Of course
-  if the screen size changed (e.g. from 320x200 -> 640x480) we can't just
-  revert to the old screen size -- unless we augment the API accordingly,
-  and update all engines to deal with this possibility.
-
-#######################################################################
-# Tools
-#######################################################################
-
-General
-=======
-* Try to unify the usage of the compression tools, where possible /
-  necessary.
-* Make compress_san use the common encoder "API" in compress.c
-* Make compress_queen use the common encoder "API" in compress.c
-* Add FLAC support to compress_sword1 (and the sword1 engine)
-* Consider using library APIs to encode data, instead of invoking the
-  lame/oggenc/flac binaries.
-  Pro: Tighter integration, no need to create temporary files.
-  Con: Requires the resp. libs/headers to be compiled in, and the resulting
-       binary would only run if all needed shared libs are present 
-       (unless we static link), whereas the current binary will work even
-       if lame/oggenc/flac are missing
-
-Descumm
-=======
-* Turn it into a library, to be used by a command line frontend (like now),
-  ScummVM debugger, and ScummEX. Basically, the API could consist of a single
-  function, which takes a pointer to a memory buffer, its length, the Scumm
-  version and optionally a game id. Also, it would get a pointer to a print
-  function (in the case of the CLI tool, print to stdout; for ScummVM, print
-  to our GUI console; for ScummEX, append to some window/widget)
-* Rewrite code to use 2 passes; first pass builds an intermediate graph, the
-  second pass then tries to detect loops, break/continue statements etc.
-* Proper implementation of o6_startObjectQuick decompilation (see comment in
-  descumm6.c). May requre rewrite of core program logic