|
|
| Line 61: |
Line 61: |
| If there's enough time, it would also be possible to add some missing WME Lite features: for example, video support (which is probably most important) and sprite frame mirroring, rotations and blending modes. | | If there's enough time, it would also be possible to add some missing WME Lite features: for example, video support (which is probably most important) and sprite frame mirroring, rotations and blending modes. |
|
| |
|
| == Audio/MIDI Device Configuration == | | == Audio Output Configuration == |
|
| |
|
| Technical contact: [[User:LordHoto|Johannes Schickel]]. | | Technical contact: [[User:LordHoto|Johannes Schickel]]. |
|
| |
|
| 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:
| | ScummVM needs an improved internal API and user interface for selecting and controlling audio output. Among other issues, at present there isn't a clear distinction between audio ''types', audio ''drivers'' and audio ''devices''. |
| * 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.
| | The idea is that a proper layer-based audio output system should be designed, implemented and used in all our engines, and an appropriate configuration GUI should be designed and added too. |
|
| |
|
| 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.
| | See [[OpenTasks/Audio/Audio Output Selection]] for more discussion and some technical details. |
|
| |
|
| See [[OpenTasks/Audio/Audio Output Selection]] and [[OpenTasks/Audio/MIDI Device Configuration|OpenTasks/Audio/MIDI Device Configuration]] for more details.
| | == MIDI Device Configuration == |
|
| |
|
| Suggested goals for the audio output configuration:
| | Technical contact: [[User:LordHoto|Johannes Schickel]]. |
| * Design a proper layer based audio output system.
| | |
| * Implement the API.
| | At the moment, configuration of MIDI output is not linked to devices, despite a lot of the configuration options being specific to a device or driver. |
| * Adopt all engines to use it.
| | |
| * Adopt the GUI to reflect the changes.
| | This task would involve designing and implementing an interface for querying and storage of a wide variety of MIDI drivers/devices, improving the GUI to allow this configuration, and working on some related improvements (such as allowing devices to be added/removed while ScummVM is running). |
| * (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!)
| |
|
| |
|
| Suggested goals for MIDI device configuration:
| | See [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details. |
| * 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.
| |