Ahriman's Prophecy Forum

Edit: Short version: Crosstie is adequate. Game has SFX but no BGM or Mouse. Playable.

I had trouble with the sound but a simple installation of DX9 Legacy seems to have fixed it.

Be aware that the game also requires a Font Patch (http://www.amaranthia.com/modules/wfdownloads/viewcat.php?cid=9).

The crosstie file will take care of both things. It should be ready in a few more days.

Urgh.

Crosstie not working.

Cxinstall breaks during the installation of the game, so the post-dependency patch is not executing correctly, and sometimes not even the virtual desktop is set as specified.

How does one debug the installation process?

You probably don't have to -- the tie here relies on a postdep
that's not yet published - that will break things generally...

Oh! Well, let's try it!

Edit: RM2K Patch crosstie is now online, and the installer still breaks.

This game's crosstie should install MDX9 Legacy, then install the game, then reboot, then tweak the registry to use a virtual desktop, then run the patch. Cxinstall breaks during installation, skipping the reboot and (sometimes) even the registry tweak. It skips straight to the patch, and that seemingly runs fine, but actually fails, I imagine because it cannot find any RM2K games in the bottle. Any ideas?

Okay, it's very, very close to working.

The RM2K Font Patch just installs two fonts to the windows/fonts folder, so it doesn't have to be a post-dependency.

Ahriman's Prophecy.tie is correctly installing the fonts and MDX9 Legacy, then the game itself. But if you run the game right away, with winewrapper.exe still running, the virtual desktop setting will be ignored (which might mess up your desktop), and the new fonts will not be detected.

If you wait a bit for winewrapper.exe to die, but before winedevice.exe does, and run the game, the virtual desktop will show up, but the fonts will still be "missing."

Finally, if you wait until both winewrapper.exe and winedevice.exe end, and then run the game, it looks perfect.

It does not matter if both the game and the patch ask for the bottle to be rebooted or not.

Is there a setting for killing those wine processes?

Those processes won't be running of their own accord ; something (a win32 exe)
would have instantiated them - it's best to ascertain which. You don't really
want to kill those processes anyhow I don't think ... if the situation is as
you describe it, users may simply have to exit things and wait for the crosstie
to complete before attempting to play the game. I have a number of tie with
install notes like that ; if people read & obey installnotes, there is no real
problem, right? (B

But the crosstie does complete. Cxinstall reports everything installed correctly, and I close it, and the wine processes keep running for about a minute or two.

Oh, well. Maybe that's what I need to put in the install notes. "Wait about a minute before running the game."

It finally occurred to me to run this thing in Windows at work, just to see what it uses. Here's the list of DLLs it pulls:

ntdll.dll
quartz.dll
msvcrt.dll
wdmaud.drv
MMDevAPI.DLL
winmm.dll
DSOUND.DLL

I don't think I've tried to install MS VC, or to have dealt with whatever wdmaud.drv and MMDevAPI.DLL are. And the music is not bad, it's be nice to get that in Linux, too 😊

Also, maybe we're lucky and one of these DLLs could fix the mouse issue (my vote is on MS VC).

Edit: Sigh. Most of those are OS components.

Found why BGM isn't working - 'Harmony.dll' - it's actually a MIDI sound library, so at
a guess it doesn't go anywhere near system midi/sound -- this dll/midi library/player
is supposed to handle it.... I'll keep digging...

Alejandro Moreno wrote:

It finally occurred to me to run this thing in Windows at work, just
to see what it uses. Here's the list of DLLs it pulls:

ntdll.dll
quartz.dll
msvcrt.dll
wdmaud.drv
MMDevAPI.DLL
winmm.dll
DSOUND.DLL

I don't think I've tried to install MS VC, or to have dealt with
whatever wdmaud.drv and MMDevAPI.DLL are. And the music is not bad,
it's be nice to get that in Linux, too 😊

Also, maybe we're lucky and one of these DLLs could fix the mouse
issue (my vote is on MS VC).

Edit: Sigh. Most of those are OS components.

I think I may have an idea about what goes wrong here. When harmony.dll loads, it uses mmdevapi.dll
to interrogate the system vis a sound replay device target - it never gets this. I believe the actual
sound device target it's looking for, is something like the windows soundcard driver's softsynth interface
which may possibly be part of the -soundcard- drivers, not windows itself. When I look at this, in debug,
the trace is strangely quiet (compared to a directsound/directmusic app trying to access functions),
in fact, to the point of there being no inklings or trace at all, nada. Most peculiar - I'll have to look
at some extreme debugging options and see if I can turn up further clues...