| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix up SCI0_LATE variant of the driver so that it actually plays anything (and even correctly). SCI1 hasn't seen any testing from me so far. I don't know whether that version works. Same for SCI0_EARLY...
|
|
I haven't found an elegant and non-intrusive way to squeeze SCI0 support into LordHoto's existing code. The drivers are too different. So I made some rearrangements. The basic mechanisms of LordHoto's SCI1 code should remain the same as before, though. I only introduced some more classes, moved some code into these classes and renamed some things (mainly for myself, so as not to get confused).
I fixed two voice mapping bugs in the existing driver code. The first bug in bindVocies() effectively hindered the driver from playing anything at all when the CMS_DISABLE_VOICE_MAPPING #define wasn't set (_voice[i].channel == 0xFF instead of _voice[i].channel != 0xFF). The second bug in unbindVoices() was not a complete show stopper, but the function simply did not "unbind the voice". The line which does the actual removal of the channel assignment was missing.
The SCI0 driver portions have been tested with: PQ2, KQ4, LSL3, QFG1, ICE and COC.
SCI_0_EARLY versions apparently don't support the CMS. At least I haven't seen a driver file so far. And there seems to be no no instrument patch resource. Although the latter issue needn't necessarily be one, since the patch data array in the driver is actually preset with data (which gets overwritten as soon as a patch file is loaded). Maybe this would work for SCI_0_EARLY. However, I haven't tested this, since I really would have have a look at a driver file first if one actually exists. For now, I have limited the driver to SCI_0_LATE.
SCI1 has been tested with KQ5 and LSL5 (not extensively, just to see whether anything got broken and whether my voice mapping fixes work).
|
|
(somewhat difficult to make out any difference, but it does affect the envelope processing)
|
|
|
|
Conflicts:
engines/sci/engine/script_patches.cpp
|
|
|
|
FOA Amiga uses 'ROL ' resources (unlike MI2 which has 'AMI ' resources). So our imuse player treated those as MT32 tracks playing on a non-MT32 device and applied GM mapping. Which of course messed up the instruments.
|
|
(several function declarations in imuse_internal.h)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removed unnecessary '\0' byte written after a string. Reasons to remove:
1. Hamlet game does not write 0 after string when running this code:
var SomeFile = new File((Game.SaveDirectory + "\gamelet.save"));
SomeFile.OpenAsText(2);
SomeFile.WriteText(LVL_N);
SomeFile.Close();
2. Original WME does not have this:
https://github.com/retrowork/Wintermute-Engine/blob/master/src/engine_core/wme_base/SXFile.cpp#L303
|
|
|
|
|
|
Assertion was caused by providing "saves/" prefixed string to
WindowsFilesystemNode::getChild() function, that asserts on '/'
characters.
Wintermute game code:
if(!(Game.FileExists((Game.SaveDirectory + "\gamelet.save")))) {
Directory.Create(Game.SaveDirectory);
}
...
Assertion stack:
from C:\WINDOWS\System32\KernelBase.dll
from C:\WINDOWS\System32\msvcrt.dll
(this=0xcfdf710,
n=...) at backends/fs/windows/windows-fs.cpp:158
n=...)
at common/fs.cpp:68
(filename=...)
at engines/wintermute/base/file/base_disk_file.cpp:76
at engines/wintermute/base/file/base_disk_file.cpp:105
this=0x50795e0, filename=...)
at engines/wintermute/base/base_file_manager.cpp:326
(this=0xcea72f0,
script=0xcf657d0, stack=0xcf6a2e0, thisStack=0xcf69ee0,
name=0xcfd8870 "FileExists") at
engines/wintermute/base/base_game.cpp:1523
...
|
|
Source:
http://docs.dead-code.org/wme/generated/scripting_ref_directory.html
|
|
Source: https://steamdb.info/app/222160/depots/
|
|
Hopefully fixes the build
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This warning will not only show up if a tag is actually unrecognized but also in cases where the tag is recognized, but the resource size is 0. This happens quite a lot in the Amiga version of MI2 with 'SOU ' tags.
|
|
The audio track is not broken. LEC simply didn't make good euphony music tracks for the FM-Towns. There is nothing we can do about that.
The TODO implies that someone should mess around with the audio data (change the composition?).
|
|
- move mac, pc speaker and fm-towns ims sound drivers into separate directory
(AdLib and MT32/GM drivers are still too entangled with common code to be moved so easily, especially MT32/GM. It would require lots of changes to the common code and possibly to all engines using the MidiDriver class. So I leave that for now.)
|
|
This fixes the issue that some rhythm instruments didn't receive correct notes. The changes have been limited to the Amiga versions.
|
|
|
|
(applies to MI2 and INDY4)
|
|
|
|
|
|
|
|
|
|
|
|
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
|
|
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
|
|
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
|
