Open main menu
ScummVM :: Wiki

Talk:TODO

We should revamp this page to distinguish better between things that clearly should be done, and ideas resp. visions resp. crazy ideas... ;). It would also be nice if we could give a rough estimate as to how difficult a task is, and how big. --Fingolfin 08:45, 4 April 2010 (UTC)


Ideas and TODOs

The following is another list of ideas and TODOs (originally due to Fingolfin, who left the project). Feel free to remove these, or add some of them to the TODO list, or whatever.

Usability

  • Check for the presence of all required data files in all games; or, as a somewhat less extensive measure, at least do this: For games which were shipped on multiple volumes (floppies, CDs), check for the presence of at least one file per volume.
  • Check for the presence of our external support files like kyra.dat, sky.cpt, etc., and also verify that they are up-to-date. For details, see FR #1520433
  • we really should handle more errors, and handle them better. In the launcher, in engines, in backends... just everywhere.
  • make "mass add" the new default behavior for the "add" button in the launcher
  • finalize dealing with the windows console, in particular
    • hide it by default
    • add a hotkey to toggle its visibility
    • implement OSystem::displayLogFile() for Windows
    • ...

Build system

  • add a --with-sdk or so switch to configure, which can be used instead of setting env vars like PSPSDK etc -> better support for automatic re-configure runs

Buildbot

  • run unit tests on build bot (for this, simply add an extra "test" builder alongside the other builders, which uses the regular build chain, but runs "make test" instead of doing a regular compilation. It wouldn't produce a "package" as output.
  • add scummvm-tools to buildbot, so that users can get nightly build of the tools (ideally with UI) for at least Windows, Linux, Mac.
  • provide windows installers from buildbot for scummvm and the tools

OSystem

  • get to rid of the evil global gBitFormat! We are mostly there now, outside of the graphics/ directory only the WinCE port access it for a single scaler. Once this has been moved to graphics, we can make gBitFormat local and then finally replace it by using PixelFormats.

Misc

  • get rid of printf in frontend code. This has been mostly achieved now, but some uses remain, mostly related to detecting / adding games. there was an extensive discussion on -devel on how to resolve this, now only somebody needs to work on advancing this.
  • Follow some consistent naming patterns for functions/methods:
    • A method which return an object pointer and expects the calling code to delete the object after use, should be named makeFOO; so for example, FSNode::openForReading() would become FSNode::makeReadStream()
    • A method which is supposed to free/delete/dellocate something should have a consistent name. Maybe freeFOO? deallocFOO? destroyFOO?
  • Remove the 'SearchMan.addDirectory' calls from runGame in base/main.cpp. Reason: Their presence causes an asymmetry between the "detect a game" and "run a game" use cases, as different files are "seen" in each case. This can lead to subtle bugs, and also causes ugly code duplication in the AdvancedDetector code right now (there to work around asymmetries like this one)
  • add plugin API to fetch a fresh desc string for a given target ?!?
  • completely get rid of #pragma pack for increased portability (what I mean here is not to simply remove it, but rather to change code which relies on structs to be packed to not do so anymore)
  • rename scummsys.h; and/or split it (types.h, defs.h ... ?)
  • Implement a "Main" class, from which backends derive. The "Main" of each backend then would become:

<syntax type="C++"> int main() { Main *m = new MyCustomMain(); int retval = MyCustomMain->run(); delete MyCustomMain; return retval; }

class Main { StringMap settings; String command; String specialDebug;

OSystem *system; public: virtual int run(int argc, const char *argv[]) { registerDefaults(); parseCommandLine(argc, argv); // A port w/o command line would simply set settings to a more suitable value

loadConfig(); PluginManager::instance().loadPlugins();

system.initBackend();

system.setWindowCaption(gScummVMFullVersion); }

int registerDefaults() int parseCommandLine(int argc, const char *argv[]); void loadConfig(); int processSettings();

int runLauncherDialog();

}; </syntax>

  • merge EventManager::shouldQuit and shouldRTL: many places need to check *both* anyway, but this is often "forgotten" (and this problem then quickly proliferates, because people use copy&paste but don't read the docs). it would be more intuitive if they were combined into one:

<syntax type="C++"> 

 QuitRequest shouldQuit()
 
 enum QuitRequest {
 	kNoQuitRequest = 0,
 	kRTLRequest = 1,
 	kQuitRequest = 2
 }

</syntax> This would also reduce the calling overhead slightly, as now only one virtual method has to be called now instead of two).


Wild unsorted ideas

  • use IdeaTorrent for ScummVM?
  • revamp TODO page in Wiki; distinguish better between things that clearly should be done, and ideas resp. visions resp. crazy ideas... ;)
  • design a smooth cool new UI


  • TrueType support for GUI
    • improved GUI experience for small devices *and* "big" devices ?
    • helpful for localization
  • add support for saving/loading from the GMM in more engines
    • some engine authors claim this to be impossible. This is false stated this way; what is true is that it might be very difficult to achieve for games using scripts to control save/load. Some ideas to hack those anyway: One needs to find out which script to invoke, at which offset, with which params.
      • locate scripts relative to others: "the verb script is N, then the load script is N+5"
      • instead of using script *byte* offsets, use instruction offsets (automatically skips over embedded translated text messages correctly)
      • ... more techniques possible ...
  • add support for freezing/saving/restoring/unfreezing arbitrary games at arbitrary points (even in mid-video)
    • very difficult, requires work on all levels: backends, engines=frontends, glue code (e.g. video player)
    • reward: Ability to suspend/resume ScummVM, super great for cell phones
    • backends could support setting offsets for "getMillis" so that the engine doesn't even notice the time shift (helpful for syncing etc..
    • videos would have to store the current offset and restore accordingly
    • engines would have to add support saving at semi-arbitrary points in time. No script based saving! instead save full engine state
    • incompatible save state format compared to "native" engine save format, but far more flexible.
    • Drawback: Harder to use game's built in save/load :/


  • Should we add a mandatory "engineid" to all ScummVM game targets? This would reduce pressure on gameid usage. Reduces requirement to load all engines just to detect which is the right one when starting a game.


  • investigate status of key (re)mapper
    • GUI part? non-GUI part?
    • does it work?
    • how does it work?
    • which backends make use of it?
    • for the others, what needs to be done to fix this?
    • what about engine support? i.e. letting engines specify which "keys" a given game wants?

Wish list

ScummVM supports many many games. Not just that, it also supports many variants of each of these games. Unfortunately, often bugs will only occur in one specific variant of a game, so unless you happen to own that particular version, it is very difficult to fix the problem (think of surgery while being blindfolded, with one hand tied behind your back).

In particular, being from Germany, I often only own the german version of a given game. While that is on the one hand useful (we have quite a big user base in Germany, it seems), the drawback is that often I lack an english variant, making it that much harder to work on bugs reported by English users.

Due to all this, here is a list of games resp. game variants that I lack and which might be useful. If you have a spare copy of any of these, feel free to donate it. I am only interested in originals, though, no warez! In addition, I also try from time to time to obtain these games e.g. via Ebay, so make sure to ask me before sending me anything, just in case I bought it in the meantime :-)

  • SCUMM
    • Zak McKracken: FM-TOWNS (OK, I am probably being unrealistic here :-) ), classic (V1) English, any other languages
    • Indiana Jones and the last Crusade: EGA German
    • Loom: FM-TOWNS (see above), EGA German
    • Monkey Island: EGA (*any* language, English or German preferred)
    • Indiana Jones and the Fate of Atlantis: Mac version
    • Sam & Max: German PC
    • The Dig: Mac version
  • Others
    • Any AGI games


Dreams about what we might want to do one way

Redesigning the option dialogs in the GMM and the Launcher.

Reducing the size of the ScummVM executable

Excerpt from a mail on scummvm-devel, 2008-11-12, Subject: "Re: ScummVM binary size comparison" 

  We are considering removing the XML parser altogether, and instead
  using an external tool to convert the theme XML (and later, the
  virtual keyboard XML) into a binary format, which would be a lot more
  compact than XML, and even could contain image data. Validation of
  the XML would be done externally,  too (using DTD / XML Scheme /
  RelaxNG). This would probably cut  50-100k from the current code
  size. The binary theme like would have  to be regenerated for new
  releases.

Things that bug me about some of our GUI dialogs

Excerpt from a mail on scummvm-devel, 2008-10-30, Subject: "Re: Fwd: PS2 backend - up & running (almost)"

Launcher options dialog:

  • Audio tab: the "Subtitle speed:" and "Text and Speech:" should IMO be aligned along the ":" with the other two labels.
  • Audio tab: The "Text and Speech" button should be wider, right now it display "ech and Subtit" for me, instead of "Speech and Subtitles" ;). Maybe turn that into "Speech & Subtitles", too, to save two chars
    • Is this fixed? The -g1x GUI now uses the shorter "Speech & Subs". --salty-horse 21:40, 23 February 2010 (UTC)
  • Volume tab: Align the three labels along their colon? (probably means setting them to be right aligned)
  • Misc tab: The rendered popup is not wide enough to display the full renderer name. But we could grow it a bit, by moving the label more to the left, that might be sufficient.

Launcher game edit dialog:

  • On the audio tab, if the Override checkbox is *not* active, all items are supposed to be grayed out. The popup button, however, is not.
  • Volume tab: See options dialog

GMM (global main menu), triggered right now via F6 in SCUMM and other games:

  • The "RTL" button is not wide enough to show its complete text -> could make it a lot wider, or shorten text?
  • the options dialog in there has a Speech & Subtitles which is not wide enough (like in the launcher)
  • also in the GMM options dialog, I would consider right-aligning the widget labels.

Nintendo DS backend + common build system

It should be possible to get the Nintendo DS backend to build using our common build system. This way, we could compile it with buildbot, too. And future work on a plugin version would be simplified.

The biggest obstacle right now is that it needs to compile C++ files with at least three different sets of options: 1) For ARM v7 2) For ARM v9, optimized for speed 3) For ARM v9, optimized for size (the default for most files) If the goal is simply to enable test compilation on the buildbot, this is not strictly necessary. But in order to compile actually usable binaries, support for this is mandatory. So we need to come up with a way. One idea: Allow overriding CXXFLAGS for arbitrary files by checking for CXXFLAGS-filename env vars, like "CXXFLAGS-foo/bar.cpp". Another approach: use target specific variables in GNU make, like this one: 

  engines/scumm/actor.o: CXXFLAGS += -DFOOBAR

or this slightly more sophisticated one: 

 engines/scumm/actor.o: CXXFLAGS := $(subst OLD,NEW,$(CXXFLAGS))

which replaces "OLD" by "NEW" inside CXXFLAGS

There are other issues... to be documented here, or resolved.

More TODOs

Initially these had been on LordHoto's TODO list. But they are meant as general TODO entries. They need to be brought into a better shape before we can move them to our TODO list though.

MIDI

  • Get rid of the current MidiParser design. It would be nicer to have two different objects instead. One called MidiParser, this time really only taking care about *parsing* the data. And nother object called MidiPlayer which takes care of passing the MIDI data to the MidiDriver and handling all other state code related to playback. This way it is easier to write custom players, like required by SCUMM and SCI.
  • Create a proper XMIDI implementation. After implementing proper MidiParser+MidiPlayer APIs, it would be easy to implement a proper XMIDI player, which is able to play 4 sources simultaneously like XMIDI is supposed to. Currently the Kyra Engine contains a rather hacky XMIDI implementation. This features proper channel locking, like the original Kyra XMIDI implementation did. This could be used as a base for writing a proper common XMIDI player.

Backends

  • Get rid of ModularBackend by modifying the whole OSystem API to use managers for the various functionalities offered. It should be taken care here not too have too small managers to avoid any bloat.
  • Fix the OpenGL backend.
    • Fix the resize handling. It would probably be best to limit the minimum overlay resolution to the minimum of the current game resolution and 320x200 and scale the overlay if the user resizes the window smaller than that. Furthermore the code should never switch to a different window size the user's window manager requested.
    • Do not expose all implementation detail of the OpenGL backend base class to subclasses. Instead proper hooks/functions should be used to set up the state of the generic functionality.
    • Move responsibilities between the SDL OpenGL backend and the OpenGL backend class, so no generic functionality is handled in the SDL subclass. It should be taken care here, that only functionality which can also be used by small devices is in the OpenGL backend class here. If desktop/console ports require extra features one could consider adding another base class.

Plugins

  • Add proper API/ScummVM version number handling to the plugin code. This should make it finally possible to create third party engines for ScummVM and use them with stable releases. On the contrary this will probably require a more stable common API in ScummVM to be really usable.
  • Change the way codecs like MP3, OGG/Vorbis etc. are supported to ease plugin support. Currently in case a plugin was build with MP3 support and it is tried to run it with a ScummVM main binary without MP3 support it will result in unresolved symbols. Instead we should consider to have dummy make*Stream functions in ScummVM's main binary even when no support for the codec is built in, which just returns NULL to indicate an error.
  • Allow out of source builds of plugins in our configure/make based build system. It should make it easier to build third party engines.

--LordHoto 01:03, 4 July 2011 (UTC)

Retrieved from "https://wiki.scummvm.org/index.php?title=Talk:TODO&oldid=16673"
Return to "TODO" page.