mirror of
https://github.com/libretro/scummvm.git
synced 2024-12-15 22:28:10 +00:00
ff6814f19b
svn-id: r18928
484 lines
24 KiB
Plaintext
484 lines
24 KiB
Plaintext
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...
|
|
- ...
|
|
|
|
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:
|
|
- common/scaler* stuff should either be moved to graphics/, or maybe
|
|
to backends/ (while it is portable code, it's something to be used by
|
|
the backends only)
|
|
- consider moving the MIDI stuff from sound/ to sound/midi/
|
|
- move fmopl code to softsynth dir
|
|
- move fonts to graphics/fonts/ dir
|
|
- move all the game engines into a new dir engines/
|
|
- maybe common/system.h / system.cpp should go to backends/, too ?
|
|
- move the iMuse source files in scumm/ to a new dir scumm/imuse/
|
|
* 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.
|
|
|
|
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.
|
|
* Split it into a Config Manager, and a Config File class. Maybe even follow
|
|
the pentagram (http://pentragram.sf.net) approach and have three class:
|
|
- SettingsManager (like our current ConfigManager)
|
|
- ConfigFileManager (manages a set of config files, possibly merging the data
|
|
from multiple config files)
|
|
- INIFile (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.).
|
|
|
|
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.
|
|
|
|
|
|
#######################################################################
|
|
# 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
|
|
|
|
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
|
|
* Indiana Jones and the Last Crusade EGA: Add inventory support for Macintosh version
|
|
* 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?)
|
|
* Eventually I would like to get rid of the "driver" sub-directory. We already
|
|
have a cross-platform infrastructure for ScummVM, so this separation is not
|
|
necessary.
|
|
* 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.
|
|
|
|
SIMON
|
|
=====
|
|
* Add support for auto decrunching the gameamiga file of demo version of Simon
|
|
the Sorcerer 1 (Amiga) via decrunch_file_amiga()
|
|
* Add support for dictionary files in Amiga and Macintosh versons of
|
|
Simon the Sorcerer 2
|
|
* Add support for Protracker music format used in Amiga versions
|
|
* Add support for drawing main graphics correctly in Amiga versions
|
|
|
|
SAGA
|
|
====
|
|
- legacy items -
|
|
* Remove any traces of the additional level of abstraction reinherit used
|
|
* Remove homerolled high level data structures like stacks that should
|
|
be provided by ScummVM if they aren't already.
|
|
* OO'ify (blah_mod.h contains public stuff, blah.h private stuff) [almost
|
|
done]
|
|
|
|
- bugs/misfeatures -
|
|
* Make actor animation Event-driven. See FIXME in actor.cpp. Maybe it
|
|
should be INTERVAL_EVENT
|
|
* No script func should use ScriptDataWord directly. All of them should
|
|
be converted to appropriate data types via getTYPE() functions
|
|
* Fix the usage of Rect so that it's more consistent with the rest of ScummVM,
|
|
e.g. a rectangle covering the entire ITE screen should have right=320 and
|
|
bottom=200. (eriktorbjorn, partly - mostly? - done)
|
|
* Inspect Font module - free memory, GameFontIds <-> FONT_ID
|
|
* Walk bug. When announcer puts medallion on Rif he should go backwards
|
|
instead of turning and walking faced to screen
|
|
* In many places RSC_LoadResource() is called but memory is not freed
|
|
afterwards, i.e. there is a huge leak
|
|
* Optimize screen output. Now we blit whole screen for each frame.
|
|
* When using the original XMIDI music resources, some songs play at the wrong
|
|
speed. The worst example I've heard of this is the "Elk Fanfare" during the
|
|
intro. It could be the meta events we don't handle, but at least the tempo
|
|
event doesn't seem to make any difference. Maybe something in the data
|
|
header instead...?
|
|
* In the dog's castle at guards' room (scene_change 177 ang go down) subtitles
|
|
aren't shown. In floppy version there is complete silence both textual and
|
|
audial. Looks to me as if subtitles are drawn outside the screen. Are the
|
|
coordinates calculated wrong, or should the text drawing code compensate?
|
|
* Sound in old Win demo is all wrong -- either there is some unique sound
|
|
format or I didn't guess it correctly
|
|
* Up and down keys ('u' and 'd') in converse panel do not work properly
|
|
|
|
- plans -
|
|
* Remove use of floating point, especially doubles.
|
|
* Implement Verbs (h00ligan)
|
|
* Implement ShowSaveReminder(), that is that diskette
|
|
* Implement Save/Load
|
|
* Finish inventory code
|
|
* Implement ISO path finder
|
|
* Hook conversations to scripts (partly done)
|
|
* ISO - tile scene implementation
|
|
* Puzzle
|
|
|
|
- features -
|
|
* Add sound/voices compression. Should _considerably_ save space.
|
|
* Add support for Mac versions. All data is in BE mode and structures are
|
|
aligned. (h00ligan, partly done)
|
|
* Support for later Win32/Mac/Linux demos where some scenes are substituted
|
|
with LBM images, tables are in place.
|
|
* Amiga ITE support
|
|
* Support for Dream Guild's Mac ITE
|
|
* Support IHNM
|
|
|
|
#######################################################################
|
|
# 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
|
|
===========
|
|
* Update it to support the latest OSystem changes
|
|
* Make it work with multiple bitdepths
|
|
* 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.
|
|
|
|
|
|
#######################################################################
|
|
# 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
|