mirror of
https://github.com/libretro/scummvm.git
synced 2024-12-24 02:36:27 +00:00
5645fa4266
svn-id: r10739
144 lines
7.4 KiB
Plaintext
144 lines
7.4 KiB
Plaintext
General
|
|
=======
|
|
* Add plugin system (both dynamic & static plugin support)
|
|
[if you want to work on it, ask Fingolfin about this, he already has done
|
|
some planning. Also make sure that your system support 'static' plugins, too]
|
|
* 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?
|
|
* add iterators to List<> template and make use of them
|
|
* allow for return-to-launcher instead of a normal "quit" ?
|
|
* improve the argv (command line args) parser
|
|
* extend the Plugin API to provide for "game detection": instead of the
|
|
TargetSettings::detectname "hack" to detect files, provide a callback
|
|
in each Plugin which given a FSList returns a list of candidate targets.
|
|
This way, a plugin can implement tests more elaborate than filename
|
|
checking, e.g. it could actually peek into the files.
|
|
* 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".
|
|
|
|
GUI
|
|
===
|
|
* implement "tabs" for multi-pane prefs dialog
|
|
-> could also be used by the Scumm help dialog in scumm/help.cpp
|
|
* LAUNCHER: fix global options dialog to be properly persistent
|
|
* LAUNCHER: add more options to global options dialog
|
|
* LAUNCHER: add more options to game target options dialog
|
|
* global & game target options dialogs probably could share some "panes"
|
|
-> write code allowing this
|
|
-> also, 'in game' option dialogs (for volume/scaler/etc. settings)
|
|
could potentially reuse these, too
|
|
|
|
Audio
|
|
=====
|
|
* Get the high quality resample code to work
|
|
[Fingolfin has started work on this]
|
|
* Add a command line/config file option for the output sample rate (to allow
|
|
for output sample rates other than 22050 Hz, e.g. 44100). Code should do
|
|
sanity checking (e.g. restrict to rates between 8000 - 65535 Hz)
|
|
|
|
Config
|
|
======
|
|
* Preserve comments in config file somehow
|
|
* 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.
|
|
* Change backends to directly access the config manager
|
|
* During the config rewrite, some command line switches were disabled.
|
|
Gotta decide what to do about each of them: reimplement, remove, replace?
|
|
In particular: -w and -l (those were kind of oddball switches, IMHO);
|
|
also -z should be split into two seperate functions (see TODO comment in
|
|
GameDetector::list_games())
|
|
|
|
SCUMM
|
|
=====
|
|
* Fix C64 costume code
|
|
* Make it possible to restart games properly
|
|
* Add support for handling Kanji in FM Towns games (foreground is rendered on a
|
|
second plane at 640x480), text uses Shift_JIS encoding
|
|
* Figure out how to extract resources from Apple II and Commodore 64 versions
|
|
* Document and fix AKOS differences in Humongous Entertainment games
|
|
* Support various newer Humongous Entertainment games
|
|
* Implement file related opcode stubs needed for Humongous games
|
|
* Add support for graphics codecs used in 3DO versions of Humongous games
|
|
* Proper handling of .tlk files for Humongous games
|
|
* Merge iMUSE and iMUSE Digital
|
|
* Implement the needed INSANE bits for Full Throttle action sequences
|
|
* iMUSE Digital enhancements/fixes for Full Throttle and COMI
|
|
* Try to remove all use of MAD/Ogg code from scumm/sound.cpp:
|
|
Ideally, only code in sound/ should access these libs. This will
|
|
become important for loadable module support
|
|
* 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
|
|
* Add support for sound effects format found in Sega CD version of Monkey Island
|
|
* Rename scummvm.cpp to scumm.cpp for consistency. [Fingolfin is working on
|
|
this, please don't do anything about this before talking to him].
|
|
1) Try to get scummvm.cpp fixed for ViewCVS [in progress!]
|
|
2a) If 1) succeeded, file SF.net CVS file rename request
|
|
2b) If 2) failed, do brute force file rename (cp && cvs add && cvs rm)
|
|
3) Adjust Makefile and project files to use the new name
|
|
* Possible implement a new resource manager, which then also could be shared
|
|
by ScummEX. [Jamieson has some ideas about this and might work on it|
|
|
|
|
Broken Sword 2
|
|
==============
|
|
* Replace all uses of std C file I/O (fopen, fread, fwrite, fclose) by
|
|
the File class (excluding that in SWORD2_DEBUG). This is probably mostly
|
|
done. I only find a few such calls in resMan::CacheNewCluster(), and that
|
|
one needs to be rewritten anyway.
|
|
* Enforce ScummVM code formatting guidelines.
|
|
* Encapsulate the code into sensible objects.
|
|
* Enable the CD swapping code.
|
|
* Support cutscenes in some kind of open video format.
|
|
|
|
SIMON
|
|
=====
|
|
* Add support for Protracker music format used in Amiga versions
|
|
* Add support for decoding main graphics correctly in Amiga versions
|
|
|
|
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.
|
|
|
|
Backends
|
|
========
|
|
* 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 :-).
|
|
* Add API to query backend for a list of available music engines
|
|
Useful for Options dialog
|
|
* Add API to query backend for a list of available scalers/screenmodes
|
|
(that is, a list of user presentable names, and corresponding PROP_SET_GFX_MODE
|
|
values). This is useful for the options dialog
|
|
* Add PROP_GET_GFX_MODE (mirroring PROP_SET_GFX_MODE)
|
|
* Consider replacing the PROP_TOGGLE_* properties with GET/SET ones ->
|
|
this allows more control over these properties (like, it allows the GUI to
|
|
display checkboxes for these in the options dialog)
|
|
|
|
SDL backend
|
|
===========
|
|
* Fix the "auto dirty rect" computing code - in particular, use a proper checksum
|
|
algorithm, this should solve many of the problems with some luck
|
|
* OpenGL code: either fix it (see open bug tracker items and various hacks in the code),
|
|
or remove it. Does anybody really need this???
|