How to get Dungeon Master II to run as fast as the PC version?

[dex]

Hey there everyone,

I compared the PC version to the Amiga version and if you look REAL CLOSE you can see that besides the awesome soundtrack the Amiga version actually looks more true to the style of Dungeon Master 1 - albeit a bit less detailed than the PC version, which in turn has a more colourful look that does not suit the game in all places.

So far the greatest trade-off of the Amiga version was the slow gameplay. So I tried to speed it up a bit by adjusting WinUAE's settings. And you "can" get it really fast - however, everything above a 68020 or even a "little" too fast settings for CPU, JIT or whatever, result in strange sound hickups. Amusingly it almost has exactly the same sound issues as "Eye of the Beholder III" with the older AESOP16 engine (just look for a playthrough on Youtube and you will hear what I mean). The sound just crackles here and there and there are hickups and "after-sounds" (TM) time and time again.

So is there a way to make the game run faster without sacrificing the sound? Which WinUAE settings could prevent that strange stuttering of the sound? Even "cycle exact" will not work if I boost the CPU a little.

[Toni Wilen]

68020 (or lower) + CE/approximate mode does not have "audio hack" enabled (that attempts to fix bad sound routines that depend on CPU speed).

Did you use 2.8.1? Audio hack was improved recently.

[dex]

Oh wow! No, I didn't try that, turns out I have an older version - going to setup the latest release and will report back, thanks Toni!

PS.: Isn't it amazing, you never ever have to worry about a thread no one answers on this board, EAB: always like coming home - just better

Hey this has actually IMPROVED! Very nice! However, the stuttering sounds are still there. It seems to take a while until they start, though. I probably have to investigate the problem a bit, I didn't try all the (new) settings but tried cycle exact with 8x CPU speed and also "fastest possible" with +100% on the CPU slider. It is not directly related the audio driver, buffer setting or audio setting as far as I found out

[Gaula92]

@Toni, could such a "hack" be implemented in FPGA Amigas like the Minimig V1.1 board or FPGA Arcade?
For example, I've observed that some games that are too slow at 7Mhz (Lucas Arts games, Waxworks...) don't sound well at 50Mhz, skipping a lot of notes.
So I suppose it's the audio player routine in these games depending on CPU, wich is a bad idea: but how did you implement that hack, so I can tell the Minimig guys?

[Toni Wilen]

Next beta will have option to force audio hack even if CPU mode is not "fast enough". Perhaps it will help..

There is nothing special in audio hack. It does three things:

1:

Old behavior: When audio DMA is switched off, audio channel was forced to idle state immediately.

New: When audio DMA is switched off, flag is set that program wants to switch off DMA, if program re-enables DMA and flag is still set, channel is forced to idle state. Flag is cleared when channel becomes idle (forced or period has counted down)

This fixes most programs that have audio DMA CPU delay loops and still allow (badly done) programs that really need delay before channel goes to idle state. Most common bug is to switch DMA off, then clear INTREQ and finally wait for interrupt bit to be set (which happens when period has counted down)

If program does not wait for idle channel, attempting to play new sample does nothing. Old sample keeps playing, only period changes.

2:

If channel is idle and program writes to AUDxDAT and period is less than 10, play nothing, go back to idle state immediately. This works around audio.device weirdness which is not that compatible with very fast CPUs (JIT).

3:

If program writes to audio pointers (high or low word) immediately after DMA has been enabled but before Agnus has seen DMAL DSR bit from Paula (Agnus has not latched channel's audio pointer): force latching immediately. This hack assumes that program wanted to update only pointer register, instead of updating current sample pointer immediately (and playing from new address)

[Toni Wilen]

2.8.2b1 has configurable audio hack (overrides automatic selection): add "chipset_hacks=4" to your config file to force-enable it. (Do not use any other values!)

(But don't forget it and later report about some other game having audio problems..)

[dex]

Hehe, no worries Toni, won't forget that However, the audio problems are still not fixed with this hack (using 2.8.2 beta 3). Do I have to add this hack to a specific section of the config or do I have to adjust the configuration in WinUAE in any way after applying this hack?

[Toni Wilen]

It can be anywhere in config file (enable logging, there should not be any "unknown config entry x" lines).

Try also fastest possible CPU modes. They work very differently compared to cycle-exact modes.

[dex]

Alright, I tried the fastest possible CPU modes (68020 or 68040 with fastest possible, with or without JIT, with or without FPU), the sound still starts to stutter after some time if the game runs at any speed above an A1200 or if set to "fastest possible".

The only thing the log says about the chipset_hacks is:
50-042 [0 000=000]: chipset_hacks is nonzero.

I am beginning to think that it may be a bug in the game/engine itself. What if it just starts reacting strangely if it runs on a fast (too fast) machine? Dungeon Master II came out late in the day of the Amiga but it may still be incompatible to certain CPUs or speeds. Does anyone have any experience with the game?

[Xebec]

Did anyone ever resolve the sound issue on 'faster than A1200' amigas? I have a mildly accelerated A1200 (68020 @ 28 Mhz, 33MB FastRAM) and it has the sound issue.. It's also still a bit slow but basically playable.