Difference between revisions of "TODO"

Jump to navigation Jump to search
430 bytes removed ,  22:36, 29 April 2006
Removing done or obsolete TODO items
(Removing done or obsolete TODO items)
Line 55: Line 55:
=== General ===
=== 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
* 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 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".
* Maybe add ways to modify the game configs via the command line. E.g. allow
* Maybe add ways to modify the game configs via the command line. E.g. allow
Line 62: Line 61:
* 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
* 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
     ./scummvm --auto-detect
* 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:
* The following things should be put into namespaces:
** AudioStream and subclasses into Audio
** MIDI related classes either to Audio, or a new "MIDI" namespace
** MIDI related classes either to Audio, or a new "MIDI" namespace
** backend specific stuff into ??? (maybe new namespace "Backends" ?)  not sure about this one.
** backend specific stuff into ??? (maybe new namespace "Backends" ?)  not sure about this one.
1,079

edits

Navigation menu