#9169 closed patch (wontfix)
GSoC: Select drivers in GUI based on output types
Reported by: | SF/sud03r | Owned by: | sev- |
---|---|---|---|
Priority: | normal | Component: | GUI |
Version: | Keywords: | ||
Cc: | Game: |
Description
Currently, in the GUI a user can select an output driver independent of what a given game supports as all concrete output implementations are shown. For example, monkey-vga supports MIDI, ADLIB and PC Speaker outputs whereas currently a user can select FM towns driver as well. However, if an inappropriate driver is selected, that selection is discarded and autoconfiguration is used instead.So a user can hear a different output while he is expecting for some other output.
In this patch, I add a call (getSupportedMusicTypes()) in metaengine to return the supported output types. The file gui/options.cpp is modified to add drivers in the list only if it is in accordance with supported output types. I have tested the same by implementing the method for scummMetaEngine and testing with monkey-vga.
The method could be similarly implemented by rest of the engines as well.
Thanks,
Ticket imported from: #2988641. Ticket imported from: patches/1274.
Attachments (1)
Change History (5)
by , 15 years ago
Attachment: | audio_output.patch added |
---|
comment:1 by , 15 years ago
While this is generally the right direction, i.e. that it should be queryable whether what output devices are supported by the game, this patch suffers from some problems:
1) It uses "gameid", if at all it should use the concrete game target not the gameid. The gameid might be the same accross different platforms variants of a game. Thus you might get "monkey" for Monkey Island 1 EGA (which supports does not support say (MT-32) MIDI without a patch) and for Monkey Island 1 VGA (which on the other hand does support MIDI) and Monkey Island 1 FM-Towns, which does support FM-Towns audio. The concrete SCUMM implementation of course suffers from the very same problem.
2) For other GUI disable/enable bits we used to have so called "gui options" for the different games. Those are actually saved inside the config file, since it might very well be required that querying those special options might require a full game detection (which might be 1) slow/overkill 2) in the future, when we finally implement full plugin support might require loading/unloading all engine plugins just for the detection bit, thus even more slow it down). This patch should probably rather go via these. There is code in common/util.h for them (check "GameGUIOption" etc.).
So I guess the way of how it should be done needs some reworking, maybe you have some ideas on how to do that properly.
comment:2 by , 14 years ago
I implemented this feature properly via GUI options, hence rejecting the patch.
comment:3 by , 14 years ago
Owner: | set to |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
comment:4 by , 6 years ago
Component: | → GUI |
---|
patch file containing the above changes.