| Age | Commit message (Collapse) | Author |
|---|
|
svn-id: r51961
|
|
(some cleanup to internal driver volume control, minor frequency change for fm-towns)
svn-id: r51930
|
|
for music fading in Kyra 1 FM-Towns and probably other FM-Towns games). This addition applies to emulated CD audio only for now. I haven't found a way to implement this for real CDs yet. SDL doesn't seem to support this (but it might be just me? If anyone knows more about this, just tell me).
svn-id: r51741
|
|
svn-id: r51709
|
|
svn-id: r51708
|
|
svn-id: r51695
|
|
svn-id: r51691
|
|
svn-id: r51671
|
|
svn-id: r51655
|
|
svn-id: r51654
|
|
svn-id: r51653
|
|
svn-id: r51651
|
|
svn-id: r51649
|
|
svn-id: r51648
|
|
- FM-Towns euphony driver completely rewritten based on KYRA FM-Towns and LOOM towns disasm.
- Split all the emu and driver code from sound_towns.cpp into different files to make things a bit less confusing.
- Move the driver code to common space since the exact same euphony driver is used by LOOM which means we could get rid of the outdated and incomplete ym2612 driver/emu implementation (which doesn't even do things like instrument loading, pan position, etc). I haven't tried to add this to the Scumm engine yet, since I am not familiar with it and my priority was to get the driver finished first. But from the look of disasm it shouldn't be difficult to do.
- Introduce a generic FM-Towns audio interface based on FM-Towns system file disasm which was necessary for the euphony driver rewrite. Every FM-Towns game I have seen so far seems to access the audio hardware via these system functions. This interface implementation will also allow reasonably simple creation of new FM-Towns audio drivers (e.g. this could be used for Kings Quest 5 FM-Towns or others).
- Move the PC98 driver to common space, too, since I have a strong feeling that this driver is also used in the PC98 version of Future Wars
- This also improves KYRA FM-Towns music quality, sound effects accuracy and music fading.
svn-id: r51645
|
|
earlier merge from trunk
svn-id: r51398
|
|
svn-id: r51373
|
|
svn-id: r51328
|
|
For use with Kyra1 Mac instrument samples. T7G Mac and Loom Mac also use this format for their custom instrument samples.
svn-id: r51327
|
|
If getDeviceHandle() gets a music driver id it will pick the driver's
first device, which should hopefully be a sensible default. E.g. it's
once again possible to use "-e alsa" rather than the much more
cumbersome "-e 'alsa_Emu10k1 WaveTable'".
svn-id: r51297
|
|
svn-id: r51296
|
|
svn-id: r51096
|
|
svn-id: r51094
|
|
svn-id: r50964
|
|
svn-id: r50926
|
|
our own statically linked version rather than relying on the system
shared lib that happens to be on most Android systems.
svn-id: r50666
|
|
were passed to detectDevice()
svn-id: r50510
|
|
svn-id: r50473
|
|
Before in case MDT_PREFER_MT32 nor MDT_PREFER_GM was specified
the code used "auto" as key name for ConfMan.get, instead of
passing "auto" directly to getDeviceHandle.
svn-id: r50472
|
|
It formerly only used the global "mt32_device" and "gm_device"
values, but we also allow game specific values, thus we take
that into account now.
Also formerly the the check for the first available MT32/GM
device only used the device handle of the mt32_device/gm_device
instead of the list of devices it iterates over. Fixed that too.
Last but not least that whole detection code looks strange to me,
it seems we only use mt32_device and gm_device for fallback
detection, at least when the music_driver matches it will always
be used. So I wonder why we have those at all?
svn-id: r50471
|
|
Along with it documented that "0" is a special device handle
for the invalid device. Now getDeviceHandle returns 0, when
the identified device could not be found.
Also getMusicType now returns MT_INVALID (newly introduced),
when a non existing device was specified.
svn-id: r50470
|
|
svn-id: r50326
|
|
svn-id: r50324
|
|
svn-id: r50296
|
|
svn-id: r50293
|
|
select MDT_PREFER_MT32 or MDT_PREFER_GM
svn-id: r50288
|
|
svn-id: r50285
|
|
svn-id: r50281
|
|
svn-id: r50158
|
|
svn-id: r50152
|
|
support caused by patch #1956501
svn-id: r50145
|
|
svn-id: r50128
|
|
The client code should never try to pass commands to
the output via the MidiParser API.
SCI currently does that though...
Actually that shows that either our MidiParser API becomes
more and more an MidiPlayer than just a parser or that the
SCI design has its flaws here.
svn-id: r49996
|
|
svn-id: r49905
|
|
svn-id: r49867
|
|
svn-id: r49844
|
|
svn-id: r49843
|
|
Proper version of patch #2988641: "GSoC: Select drivers in GUI
based on output types". So far only SCUMM engine supports this
feature.
svn-id: r49783
|
|
Since AGI distinguishes between PCSPK and PCJR/Tandy, make it as a
pseudodriver.
svn-id: r49782
|
|
Based on patch #2903830: "Updated Translation Prototype" by alexbevi
which in turn is based on patch #1739965 by jvprat.
Currently it builds all translations right into ScummVM. Once the
feature will be accepted more widely, i.e. more translations will
pop up, it will be trivial to move translation strings to external
file.
Finished translation: Russian
Unfinished translation: Hungarian
Things which are nice to do:
- Language code -> language mapping for more user friendness
- Specifying fonts to be used with language
- Updating of interface language without restart. It will require
moving of much code to reflowLayout() methods for each dialog
The .po files must be in single byte encodings. I.e. no support
for Unicode.
svn-id: r49759
|
