Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 19:02, 4 March 2011

15,005 bytes removed ,  19:02, 4 March 2011
Move OpenTasks onto unique pages with an Infobox and Category so we can collect them all up onto the summary page.
(→‎MIDI device configuration: Update MIDI device configuration task.)
(Move OpenTasks onto unique pages with an Infobox and Category so we can collect them all up onto the summary page.)
Line 51: Line 51:
But of course like with all the other tasks, we recommend that you first talk to us (see above).
But of course like with all the other tasks, we recommend that you first talk to us (see above).


== Generic infrastructure tasks ==
== Current Open Tasks ==
 
=== Improve the ScummVM build system ===
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:Sev|Eugene Sandulenko]]


''Background:''
Below is a table of all the currently open tasks that people may wish to consider working on.
These tasks can be considered in addition or in conjunction with anything on our [[TODO]], any other task or your own 'Anything you can dream of' project.


ScummVM uses a custom hand-made Makefile based build system by default. In addition, we maintain a set of project files for various versions of MSVC, and some other development environments. Some of our ports tie into the default Makefile build system, but others need yet other project files (e.g. the PalmOS port).  
The GSoC workload figure can be used to indicate the percentage of GSoC project time we consider this task will take an average competent programmer. These are just rough guides and should you feel you can undertake a task well in less time (or take longer but deliver a much better or more feature rich result) please feel free to mention this on your application and select your tasks accordingly.


This leads to the following problem. Whenever we add, move or delete files from our repository, the default build system is updated, but the other project files in general are not -- they have to be maintained separately. This is a manual task, and if forgotten, causes these project files to become out of date and hence more or less unusable. Therefore, we would like to be able to generate these project files from the master build system. For MSVC, we already do this with the help of our custom C++ tool [code]create_msvc[/code].
<dpl>
 
category = Open Tasks
Another issue is the following: There are several people who develop 3rd party engines, which use the core code from ScummVM, but are not hosted within the ScummVM repository. Since ScummVM allows building engines as loadable modules, that is fine. However, in order to ''build'' these engines, one currently has to copy them into a checkout of the ScummVM trunk, and then hook them into the build system (by modifying the [code]engines/engines.mk[/code] file). It would be so much easier if one could build an engine as a loadable module *outside* of the ScummVM source tree, and without any need to modify files in the ScummVM source tree. This is definitely doable, but needs somebody to implement it.
include = {Infobox_OpenTasks} Inforow
 
table = border="1" cellpadding="2" class="sortable" ,-, style="background:silver" | Task, style="background:silver" | GSoC Workload, style="background:silver" | Technical Contact(s), style="background:silver" | Subsystem
Then there are the ScummVM tools, which are hosted in a separate module of our repository. It would be nice if the tools could share code with ScummVM other than by copying it, e.g. by hooking into the ScummVM build system somehow. (Please ask us for details on this very vague statement if you are interested in pursuing this ;-). In addition, it would be nice to be able to generate project files for the tools, too.
</dpl>
 
All of the above needs to be implemented in a portable fashion.
 
 
''The Task:''
 
* Generate project files for various IDEs (XCode, Eclipse, ...) from the default build system. (MSVC has already been done.)
* Modify the ScummVM build system with the ability to build engines outside of the main source tree.
* Enhance the build system of the ScummVM tools (they are in a separate Subversion module, and not to be confused with the tools included in the ScummVM source tree itself).
 
An alternative approach to hand-rolling everything described above would be to switch our build system to [http://www.cmake.org/ CMake]. However, since this would be a major change for us, it would have to be carefully researched first, in particular with regards to the next point:
 
A prime requirement is that the resulting system must still work on Linux, Mac OS X and Windows, and all other platforms that use the default build system (e.g. WinCE, Nintendo DS, ...). Any negative impact on portability should be avoided.
 
''Required Skills:''
 
* Good C++ skills.
* Excellent Makefile skills.
* Possibly experience with CMake, SCons or another meta-build system.
 
=== Small Devices Backend ===
''Technical Contact'': [[User:DJWillis|John Willis]], [[User:JoostP|Joost Peters]]
 
''Background:''
 
ScummVM has been ported to many platforms, often by simply re-using the SDL backend (which is based on [http://www.libsdl.org SDL], which by itself has been ported to many platforms, making it fairly easy to port ScummVM to any of these platforms).
 
But for some [[Platforms|platforms]], dedicated backends are required, either because SDL doesn't support them, or because we can't achieve all our needs by using the SDL port (e.g. because we need more speed, more control, etc.). These backends are typically made for what we call "small systems" -- systems like PDAs, SmartPhones, Internet Tablets ([[PalmOS]], [[SymbianOS]], [[Windows CE]], [[Maemo]]), or game consoles ([[Dreamcast]], [[GP2X]], [[Nintendo DS]], [[PlayStation 2]], [[PlayStation Portable]]).
 
These systems share many features. In particular they often have no (full) keyboard and quite limited resources: Little RAM, little permanent storage space, not that much CPU power, or a limited screen resolution.
 
This makes it often necessary to (re)implement certain functionality, like virtual keyboards (see above task), or graphic downscalers and the like.
 
''The Task:''
 
Since the same needs occur again and again, it would be nice to implement such functionality only once in a sufficiently portable and flexible way, making it possible for backends to pick and use whatever they need.
 
Details, scope and further suggestions as to how to achieve this can be found on the [[Small Devices Backend]] page.
 
Besides this, optimizing code for speed and memory usage benefits all our targets. In particular these "small devices". Hence doing this is a worthy goal on its own.
 
''Required Skills:''
 
* Reasonable C++ skills.
* Refactoring skills.
* Knowledge of one or more ScummVM platform backends is desirable.


== Generic infrastructure tasks ==
=== Add a testing framework for ScummVM's subsystems ===
=== Add a testing framework for ScummVM's subsystems ===
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
Line 242: Line 195:


== Audio related tasks ==
== Audio related tasks ==
=== Audio output selection ===
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
''Background:''
Right now, our user interface and our internal API for selecting and controlling audio output are very limited. They do not properly differentiate between the output ''type'', the output ''driver'' and the output ''device''. To explain the difference:
* An output type could be MIDI, AdLib, (PC) speaker, Amiga, etc.; MIDI could be further split into GM (General MIDI), MT-32, Roland, etc.
* An output driver is a concrete implementation of an output type. For example, we have two AdLib/OPL drivers right now; and many MIDI drivers.
* Finally, a single driver could control multiple devices; e.g. you might have a General MIDI synthesizer *and* an MT-32 attached to your computer; or you might want to use fluidsynth with two different sound fonts, each shown as a separate "device".
These different concepts are currently not properly distinguished. Furthermore, the approach we use to deal with MIDI variants like GM, MT-32 and Roland, is rather weird and irregular.
This all results in a rather confusing way to select the output device -- for engine developers, for audio output developers, and for the user in the GUI. Clearly, this is a bad thing for all involved parties and hence the goal of this task is to fix this mess.
Let's start by reviewing the current state of affairs. Engines specify during a startup a set of [http://doxygen.scummvm.org/dd/d2e/mididrv_8h.html#0b8636a2c41edcf47a84282ba7a00971 audio output flags]. These flags try to describe the output ''types'' supported by the engine resp. the current game. We then use some (rather simple and stupid) "detection" method based on these to determine the output ''device'' to use. Unfortunately, this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI (in this case, MT-32 MIDI) and Amiga sound output. Now there is no (clean) way of checking whether the user wanted to use Amiga sound or MT-32 MIDI. This results in an unclean way of checking in the engine what exactly the selected output type is (this might be required to load special music data files for the different output types). To further complicate things, the current "AdLib" music device is actually an MIDI emulation device (useful on low end system which don't properly support MIDI output on their own), but on the other hand says it's an AdLib ''type'' ''device'', causing several engines which only use MIDI for audio output, and which don't contain any AdLib data, to still specify the MDT_ADLIB audio flag.
For the user, we currently always show all concrete output ''devices'' (except digital sound!) in the GUI, without distinguishing between output types and output drivers. We also always show everything, without considering what a given game actually supports. So currently the user can select "AdLib" sound for a game which does not contain any AdLib sound data. This is rather annoying.
To overcome these issues it would be best to change our audio output configuration API to use different layers of configuration:
* The first layer would be the output ''type''. As described above, this could include General MIDI, MT-32 MIDI, AdLib (or generic OPL* output), (PC) Speaker (this might also include PCjr and CMS, to be determined later on), Amiga, FM-TOWNS, Digital Output etc. Note that this is no final list, rather making this list concrete is part of the task! For example, one might want to have a single MIDI output type, and introduce a notion of ''subtype'' to distinguish between GM, MT-32 and Roland MIDI.
* The next layer would probably be a concrete output implementation, i.e. output drivers. Examples include Windows MIDI or ALSA for MIDI. Note that a single driver could potentially support multiple types: A user may usually use the Windows MIDI driver for GM output, via software synthesis, but may also own a real MT-32. This user may then wish to use the MT-32 via the Windows MIDI driver. Hence, depending on the output device resp. the user choice, the Windows MIDI driver would accept any MIDI variant. On the other hand, the MT-32 software emulator might only support MT-32 data.
* One could also insert an extra conversion layer which tries to (optionally) translate between the various MIDI variants: So if a game requires MT-32 output but the user only has a GM device available, the MT-32 data could be translated on the fly (as good as possible) to GM before being sent to the actual output driver. Such conversions currently happen in engines. Sharing this code might be beneficial; on the other hand, it might turn out that each engine knows best how to perform this translation, in which case we should leave it up to the engines to perform such a conversion (or not). Once again, deciding this is part of the task.
So if you plan to take this task, you will still have a lot of research to do, to find the best separation :-). Of course the technical contacts, as well as the rest of the ScummVM team, would collaborate with you on this.
Roughly the same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output driver like ALSA to use a specific setting (like in the output port for ALSA); think of this as a baby version of output devices (for true output devices, one would have to support multiple such configurations for each driver, configurable and selectable via the command line, GUI and the internal API). See the [[OpenTasks#MIDI device configuration|MIDI device configuration]] task for more thoughts about this. (Note that it would probably be best to tackle both tasks in a single Google Summer of Code project!)
Of course this is not set in stone yet; if you have some other great idea how to tackle this, we are happy for your feedback :-).
''The Task:''
* Design a proper layer based audio output system.
* Implement the API.
* Adopt all engines to use it.
* Adopt the GUI to reflect the changes.
* (Optionally) also extend all engines to supply a list of supported audio devices for a specific game target (this would be done via the help of engine authors).
* All configuration must be serializable for our configuration file. (And it would be nice to have some auto update feature for old configuration files!)
=== MIDI device configuration ===
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:LordHoto|Johannes Schickel]]
''Background:''
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several device drivers for various MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
Unlike the audio driver output selection task above, this task solely focues on configuration of the individual ''MIDI'' devices.
We have a few game specific settings, like "True Roland MT-32" mode or "Roland GS Mode", currently. In reality these are not settings of an individual game, but rather of a specific MIDI device. Think of it like this: When you connect your Roland MT-32 ''device'' to your first ALSA hardware MIDI port, it is pretty obvious that this device will only support MT-32 MIDI data. Currently whenever you select that MIDI device in a specific game you also have to make sure that the "True Roland MT-32" mode setting is selected, otherwise it might be that the game will send General MIDI data to the Roland MT-32, which in turn will result in odd output. This is especially annoying if you want Roland MT-32 output in a few selected games and General MIDI output in others, this way you will have to make sure that in ''every'' game's settings the device and its ''type'' are setup correctly. As you can easily see this is lots of redundant configuration effort and easy to forget.
The idea of the task now is to change the configuration of these aspects to the device layer. This means the user should have the possibility to set a certain set of options on a per device base. Think of it like this: The users has "MIDI Port 1", where is Roland MT-32 is connected, on the other hand he has "MIDI Port 2", where a General MIDI synthesizer is connected. Now the user should have the possibility to configure his "MIDI Port 1" device as "True Roland MT-32" and his "MIDI Port 2" device as "General MIDI" device. Now when he selects "MIDI Port 1" in a game it will automatically be recognized as Roland MT-32 by the game and thus the user will not have to do any special configuration in the game's settings for his output device. The same is of course true for his "MIDI Port 2" device.
In reality it is a little bit more complicated though, since we feature special devices like the "MT-32 Emulator", which of course only supports MT-32 data, thus it should not be possible to change its configuration to General MIDI, or the "AdLib Emulator", which is a General MIDI(?) emulator, here of course it should not be possible to reconfigure it as a MT-32 device. Furthermore we have certain MIDI type options, which are not present in the current GUI, like for the Yamaha FB01, which is a synthesizer only supported by the SCI engine. And last but not least we support soundfont based emulators like fluidsynth, for those it would be nice if the user could add ''virtual'' devices, which for example differ in the soundfont setup, but all get individual device entries in the configuration dialogs. In neither the current driver API layer nor the device API layer it is possible to retrieve any information on whether it is possible to configure a device in a specific way. Thus this needs to be extended as part of this task too.
Note that it would probably be best to tackle this task and the [[OpenTasks#Audio output selection|Audio output selection task]] in a single Google Summer of Code project!
''The Task:''
* Design a efficient way to query supported configuration options from a driver / device.
* Design a efficient way to save supported configuration options for a driver / device.
* The design must be easy to extend, also it must be possible to add new drivers easily.
* It must be possible to save the configuration to our configuration file.
* Configuration of a device (for single game run) via command line should still be possible.
* It must deal with devices being added/removed (at least between runs of ScummVM, ideally also while ScummVM is running).
* Devices should be configurable via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.
=== XMIDI parser ===
=== XMIDI parser ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]
DJWillis
208

edits

Retrieved from "https://wiki.scummvm.org/index.php?title=Special:MobileDiff/15997"

Navigation menu