|
|
| Line 21: |
Line 21: |
|
| |
|
| === General === | | === General === |
| * Add port specific user documentation (dreamcast/palm especially). That would include things like:
| |
| ** How to use ScummVM on system XYZ
| |
| * 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? |
|
| |
| === README / Manual ===
| |
| * A proper manual might be nice.
| |
| * Maybe move all/most of the compression related stuff from our README completely to the tools README, and only leave a pointer to that in the main README. This would be beneficial because this way, it's only documented in one place; it's *completly* documented (currently, the main README doesn't mention compress_scumm_bun, for example); and people who want to use the compression tools need to download the tools package anyway.
| |
| * 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...
| |
| ** ...
| |
|
| |
|
| == Web sites == | | == Web sites == |
|
| |
| === General ===
| |
| * Move all sites to the new host
| |
| * Update outdated software
| |
| * Use HTTPS everywhere
| |
| * Make a consistent and reusable visual look across all sub-sites
| |
|
| |
| === Primary website ===
| |
| * Add big (green?) shiny buttons in the middle of the page for (1) Donations and (2) Downloads ?
| |
| * 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.
| |
| * Introduce build tools to handle website updates
| |
| * Update the template engine
| |
|
| |
|
| === [[Buildbot]] === | | === [[Buildbot]] === |
| * Track the size of the resulting binaries. | | * Add Fribidi |
| ** This would greatly help in tracking down when and why the size of the ScummVM binary increased.
| |
| ** Doing this should not be hard. Setup a database which stores for each commit the size of the (stripped) binary of each port.
| |
| ** Then, add a way to query that database via a webfront. At first, simply dumping all the numbers would be good enough. On the long run, it would be nice to show some cool graphical diagrams.
| |
| ** For bonus points, allow the user of that webpage to dynamically change it using javascript: i.e. selecting which ports to show, which range of revisions; mousing over a data point shows a little box with details on the commit; clicking on a revision number jumps to the corresponding page in our SVN repository viewer; etc. ;).
| |
| * Install the new required dependencies (libpng and libtheora for [[Sword25]]) into the cross compiler environments of all ports that have a chance of supporting [[Sword25]].
| |
| * Install the new required dependencies (libpng, libfreetype, boost and wx-widgets) into the cross compiler environments of all desktop ports to support building of tools.
| |
| * Fix the console page
| |
|
| |
|
| === [[Doxygen]] === | | === [[Doxygen]] === |
| * Update the visual theme to better match the site | | * Make it run again, upgrade |
| | |
| === [[Forums]] ===
| |
| * Upgrade to phpBB 3
| |
| * Update the theme to phpBB3
| |
| | |
| === [[Planet]] ===
| |
| * Improve the visual theme to better match that of the forum and website
| |
| | |
| === [[Wiki]] ===
| |
| * Update the theme to match the updated website
| |
| * Update to the latest Wiki version
| |
| * Add a ScummVM style guide
| |
| * Add content to [[Special:Wantedpages|Wanted Pages]]
| |
| * Add some content to [[Help:Editing]], which is shown when editing a page
| |
|
| |
|
| == Common code, infrastructure == | | == 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
| |
| * 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
| |
| ./scummvm --add new_target --path=/foo monkey2
| |
| ./scummvm --remove new_target
| |
| * The following things should be put into namespaces:
| |
| ** MIDI related classes either to Audio, or a new "MIDI" namespace
| |
| ** 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.
| |
|
| |
| === Events ===
| |
|
| |
| ==== Event struct ====
| |
| The following is a (revision of) a former comment in <code>common/events.h</code>:
| |
|
| |
| Rework/document this structure. It should be made 100% clear which field
| |
| is valid for which event type. Implementation wise, we might want to use
| |
| the classic union-of-structs trick. It goes roughly like this:
| |
| <syntaxhighlight lang="cpp">
| |
| struct BasicEvent {
| |
| EventType type;
| |
| };
| |
| struct MouseMovedEvent : BasicEvent {
| |
| Common::Point pos;
| |
| };
| |
| struct MouseButtonEvent : MouseMovedEvent {
| |
| int button;
| |
| };
| |
| struct KeyEvent : BasicEvent {
| |
| ...
| |
| };
| |
| ...
| |
| union Event {
| |
| EventType type;
| |
| MouseMovedEvent mouse;
| |
| MouseButtonEvent button;
| |
| KeyEvent key;
| |
| ...
| |
| };
| |
| </syntaxhighlight>
| |
|
| |
| However, this approach is contrary to classic OO paradigms. Indeed, its
| |
| major drawback is that all event types now must be POD data types, so
| |
| e.g. they can't contain a Common::Point as member. Bad.
| |
|
| |
| An alternative approach would be a more OO like switch to multiple Event
| |
| subclasses. This would, however, then require us to pass events around
| |
| as pointers to object instances, and also would require introducing type
| |
| casting in code using events. The passing around of pointers could be
| |
| mitigated by using
| |
| <syntaxhighlight lang="cpp">
| |
| typedef Common::SharedPtr<BasicEvent> Event
| |
| </syntaxhighlight>
| |
| 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
| |
| off by staying with the existing monolithic struct Event, we should just
| |
| enhance its documentation.
| |
|
| |
| === Build System ===
| |
| * Add test(s) for backend usability in the configure script.
| |
| * Add an install target to the Makefile - Copy binary, install manpage, add menu items, install README. See also patch #891909 (Gnome/KDE .desktop file)
| |
| * Investigate whether switching to [http://www.cmake.org CMake] or [http://www.scons.org SCons] or some other cross platform configuration environment would work for us. Potential advantage: Less effort to maintain and extend the build system, automatic generation of various kinds of project files (Makefiles, and project files for MSVC, XCode, Eclipse, KDevelop ...). Potential drawback: Problems with the customized build systems of our various ports. However, the latter might actually be improved by using CMake or SCons -- hard to say without tests.
| |
|
| |
|
| === Audio === | | === Audio === |
|
| |
|
| ==== Mixer ==== | | ==== Mixer ==== |
| * Get the high quality resample code to work
| |
| * 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.
| |
| * Some of our engines support the speech_mute / sfx_mute / music_mute options, but most don't. Almost all support the corresponding FOO_volume config keys. All engines use Mixer::setVolumeForSoundType to push those through to the mixer. I am wondering: Maybe it would make sense to remove Mixer::setVolumeForSoundType, and instead leave it up to the mixer to query the ConfigManager for the corresponding FOO_volume/_mute values? That way we'd ensure 100% identical behavior in all engines and actually simplify the code a bit... ? Not sure if this would work smoothly, it needs to be investigated.
| |
| * the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to enforce that all backends always return a valid mixer. In the worst case, if a backend cannot produce audio output, it should still instantiate an Audio::MixerImpl, with some arbitrary sample rate (I recommend 22050 Hz), and a fake playback thread, which acts like an audio output callback but simply discards the generated audio data. (Note: It doesn't suffice to just throw away input data in Mixer::playInputStream, as this breaks with QueuingAudioStream). | | * the "isReady" code is irritating. Most engines ignore it anyway. It's primary purpose is to allow ScummVM to run even if not digitial audio out is available. A better solution would likely be to enforce that all backends always return a valid mixer. In the worst case, if a backend cannot produce audio output, it should still instantiate an Audio::MixerImpl, with some arbitrary sample rate (I recommend 22050 Hz), and a fake playback thread, which acts like an audio output callback but simply discards the generated audio data. (Note: It doesn't suffice to just throw away input data in Mixer::playInputStream, as this breaks with QueuingAudioStream). |
| * document the semantics of sound handles and sound ids
| |
| * Are there backends which could benefit from a 'custom' mixer? If so, what would be required to implement such a thing? Needs talking to porters
| |
|
| |
|
| ==== CD ==== | | ==== CD ==== |
| Line 178: |
Line 61: |
| ** ... produce a warning if an older ScummVM version tries to load a config file written by a newer version with potentially incompatible changes (such as the switch from language code "hb" to "he" for Hebrew) | | ** ... produce a warning if an older ScummVM version tries to load a config file written by a newer version with potentially incompatible changes (such as the switch from language code "hb" to "he" for Hebrew) |
| ** ... detect when we an old config file is loaded which needs to be updated (e.g. by changing language "hb" to "he"; by adding "guioptions" to targets; by fixing trailing slashes in "path"; maybe even updating old style; and maybe in the future by adding "engineid" fields to all targets) | | ** ... detect when we an old config file is loaded which needs to be updated (e.g. by changing language "hb" to "he"; by adding "guioptions" to targets; by fixing trailing slashes in "path"; maybe even updating old style; and maybe in the future by adding "engineid" fields to all targets) |
|
| |
| === Files ===
| |
| * Don't rely on the existence of SEEK_CUR, SEEK_END, SEEK_SET -- rather, define our own enum for this and convert all client code to use it.
| |
| * Try to replace all usages of paths by FilesystemNode.
| |
|
| |
|
| === GUI === | | === GUI === |
| Line 192: |
Line 71: |
| === Launcher === | | === Launcher === |
| * Enhance the Mass detector to show a list with the results (and optionally, allow the user to edit/cull that list before adding it). | | * Enhance the Mass detector to show a list with the results (and optionally, allow the user to edit/cull that list before adding it). |
| * Game edit dialog: Consider adding some warnings to the platform/language fields ("Don't mess with these unless you know what you are doing"), or move them to an "advanced" tab
| |
| * Make the gameid editable via an "advanced" tab entry? | | * Make the gameid editable via an "advanced" tab entry? |
| * <s>There is no way to reset the save/extra/theme paths. Adding a tiny button labeled "c" for clearing them (like for the soundfont path button) is not the way to solve this, I think. One approach would be to extend the Browser dialog, to allow an (optional) extra button, with customizable label. When pressed, the browser dialog closes and returns a special code. Well, and we'd use labels like "Use default savepath" or "Reset extrapath", or just always "Use default value".</s>
| |
| * The global options dialog may show a button for configuring the savepath even on systems where it is fixed -> not good. This button should be hidden/removed for these systems | | * The global options dialog may show a button for configuring the savepath even on systems where it is fixed -> not good. This button should be hidden/removed for these systems |
| * separate launcher code even more from rest of ScummVM, to make custom launchers easier? | | * separate launcher code even more from rest of ScummVM, to make custom launchers easier? |
| Line 208: |
Line 85: |
| ** Add/unify "confirm exit" dialog, globally (see [https://sourceforge.net/tracker/index.php?func=detail&aid=1731025&group_id=37116&atid=418823 FR #1731025]) | | ** Add/unify "confirm exit" dialog, globally (see [https://sourceforge.net/tracker/index.php?func=detail&aid=1731025&group_id=37116&atid=418823 FR #1731025]) |
| * Options Dialog: Implement engine flags to define which features in the Options dialog are supported by the current running game. Use these flags to hide/show the appropriate sliders and buttons in the Options Dialog | | * Options Dialog: Implement engine flags to define which features in the Options dialog are supported by the current running game. Use these flags to hide/show the appropriate sliders and buttons in the Options Dialog |
| * Allow engines to extend the GMM more freely. E.g. for the SCUMM engine, we would want to add a "Help" button. Alternatively, just always have a help button and only show/hide resp. en-/disable it as needed.
| | * Improve the look of the GMM: This could include displaying the engine name and the game name on the top of the GMM. |
| * Improve the look of the GMM: This could include displaying the engine name and the ScummVM logo somewhere on the GMM. | |
| * Config Dialog code: Resolve the FIXME in engines/dialogs.cpp which pertains to having to use the empty string as the domain name. This is a bigger task, but will enable many other changes (thus as finally changing ConfigManager to use ConfigFile). Essentially, the current game config dialog tries to abuse the system by editing the *active* settings via the config manager, in order to fully reduce the options dialog code from the launcher. But there is a big difference between editing the config settings of a specific target, and the active settings. So, one probably needs to rewrite the code for the config dialog shown from the GMM | | * Config Dialog code: Resolve the FIXME in engines/dialogs.cpp which pertains to having to use the empty string as the domain name. This is a bigger task, but will enable many other changes (thus as finally changing ConfigManager to use ConfigFile). Essentially, the current game config dialog tries to abuse the system by editing the *active* settings via the config manager, in order to fully reduce the options dialog code from the launcher. But there is a big difference between editing the config settings of a specific target, and the active settings. So, one probably needs to rewrite the code for the config dialog shown from the GMM |
| * Make it possible to reach the "key remapper" and "virtual keyboard" from the GMM, if available?
| |
| * Sugar on the cake: In addition to the ScummVM logo and version, how about showing the engine name and game title at the top of the GMM?
| |
|
| |
|
| === Error handling === | | === Error handling === |
| Line 311: |
Line 185: |
| * Add API to query backend for a list of available music engines. Useful for Options dialog. See [[Music drivers redesign]]. | | * Add API to query backend for a list of available music engines. Useful for Options dialog. See [[Music drivers redesign]]. |
| * 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 ;-) | | * 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 ;-) |
|
| |
| === 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.
| |
|
| |
| === Windows ===
| |
| * Add scripting code for creating a Windows installer to our code repository, so that a full Windows release can be built easily and directly. Could be based on [http://nsis.sourceforge.net NSIS] or [http://wix.sourceforge.net WiX].
| |
|
| |
|
| == Tools == | | == Tools == |