53
edits
Difference between revisions of "TODO"
Jump to navigation
Jump to search
Remove some obsolete TODO items
(→Common code, infrastructure: Add error handling task) |
(Remove some obsolete TODO items) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 23: | Line 23: | ||
* Add port specific user documentation (dreamcast/palm especially). That would include things like: | * Add port specific user documentation (dreamcast/palm especially). That would include things like: | ||
** How to use ScummVM on system XYZ | ** How to use ScummVM on system XYZ | ||
* Update/enhance man page | * Update/enhance man page | ||
* Write a high level overview of how ScummVM and its engines work? | * Write a high level overview of how ScummVM and its engines work? | ||
| Line 43: | Line 42: | ||
* Add big (green?) shiny buttons in the middle of the page for (1) Donations and (2) Downloads ? | * Add big (green?) shiny buttons in the middle of the page for (1) Donations and (2) Downloads ? | ||
* Show "Release Date" on download page | * Show "Release Date" on download page | ||
* Change all screenshot filenames to match our rules as described [[Screenshots|here]]. E.g. rename <code>data/screenshots/agos/simon/scummvm_2_4_0.jpg</code> to <code>data/screenshots/agos/simon/simon-0.jpg</code> etc.; also some stuff should maybe be moved to other directories. | * Change all screenshot filenames to match our rules as described [[Screenshots|here]]. E.g. rename <code>data/screenshots/agos/simon/scummvm_2_4_0.jpg</code> to <code>data/screenshots/agos/simon/simon-0.jpg</code> etc.; also some stuff should maybe be moved to other directories. | ||
| Line 77: | Line 75: | ||
./scummvm --add new_target --path=/foo monkey2 | ./scummvm --add new_target --path=/foo monkey2 | ||
./scummvm --remove new_target | ./scummvm --remove new_target | ||
* The following things should be put into namespaces: | * The following things should be put into namespaces: | ||
** 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. | ||
* Get rid of getenv in as many places as possible. Ideally, we'd only use it to query HOME on Unix systems. | * Get rid of getenv in as many places as possible. Ideally, we'd only use it to query HOME on Unix systems. | ||
==== Iterator handling ==== | ==== Iterator handling ==== | ||
| Line 99: | Line 91: | ||
is valid for which event type. Implementation wise, we might want to use | is valid for which event type. Implementation wise, we might want to use | ||
the classic union-of-structs trick. It goes roughly like this: | the classic union-of-structs trick. It goes roughly like this: | ||
< | <source lang="cpp"> | ||
struct BasicEvent { | struct BasicEvent { | ||
EventType type; | EventType type; | ||
| Line 120: | Line 112: | ||
... | ... | ||
}; | }; | ||
</ | </source> | ||
However, this approach is contrary to classic OO paradigms. Indeed, its | However, this approach is contrary to classic OO paradigms. Indeed, its | ||
| Line 131: | Line 123: | ||
casting in code using events. The passing around of pointers could be | casting in code using events. The passing around of pointers could be | ||
mitigated by using | mitigated by using | ||
< | <source lang="cpp"> | ||
typedef Common::SharedPtr<BasicEvent> Event | typedef Common::SharedPtr<BasicEvent> Event | ||
</ | </source> | ||
or something like that. Yet this would mean increased overhead in all | or something like that. Yet this would mean increased overhead in all | ||
our code, yet the gain is unclear. In conclusion, we probably are best | our code, yet the gain is unclear. In conclusion, we probably are best | ||
off by staying with the existing monolithic struct Event, we should just | off by staying with the existing monolithic struct Event, we should just | ||
enhance its documentation. | enhance its documentation. | ||
=== Build System === | === Build System === | ||
| Line 314: | Line 305: | ||
=== SDL backend === | === SDL backend === | ||
* Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. 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. | * Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. 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. | ||
=== Windows === | === Windows === | ||