The three required files are attached. I also fixed the SB OPL volume so it uses the correct level (provided by James-F) when using both types of OPL. The nukedopl.* files go to src/dosbox . I also added the ability to not use NukedOPL which will make it fall back to DOSBox OPL3 emulation. NukedOPL is enabled by default.

Good thinking including that option to switch back to the original OPL3 emulation, with NukedOPL as the default. Last I checked, the speed hit was considerable enough to be an issue when emulating faster machines, but NukedOPL's improvements are major enough to demand its use in all other circumstances IMO. This is the right solution.

Depending on your host machine and guest configuration, it's possible to get a very significant speed hit from NukedOPL. The accuracy is excellent, but of course that comes at a price. Battler's patch makes NukedOPL the default but leaves open the option to use the previous, less-accurate OPL emulation, which will be necessary for people who are trying to run games that are near the borderline of what their hardware can handle. It's the best of both worlds. I think he made the right call.

On the emulated Pentium 75, I used Little Big Adventure 2 as reference. With NukedOPL disabled, it runs at solid 100%, while with NukedOPL enabled, it runs at 85-90%. That's a 10-15% difference. And the game doesn't even use any sort of synth music, so the mere attachment of NukedOPL to the guest machine reduces performance.

Committed at rev 756. I moved the configuration option into the per-device config, as there's no reason for it to be global.

BTW, if you're going to assign 'copyright holders' to each file, could you at least try to get it right? I don't see why the DOSBox team get 'copyright' over sound_dbopl.cc/h, given that I wrote it. Interfacing with someone else's code doesn't give them copyright over the interface code.

Yes those two are missing from the source, but when included everything works as expected; big big thank you Sarah..
I don't understand why the "per-device" option because the user can't actually use more then one device, but oh well.

There are crashes with the latest commit when minimizing the window to taskbar and returning to it, I think D3D related.
But, there is still a problem with oplenAL32.dll, I'll report in the sound lag thread.

Battler, I should point that DOSBox uses the dbOPL core for OPL2 and OPL3
NukedOPL patch for DOSBox is like dbOPL applied to both OPL2 and OPL3.
According to NukedOPL author: http://www.vogons.org/viewtopic.php?f=4 ... 27#p590414
Since you ported the patch to PCem, I suggest enabling NukedOPL on OPL2 too, and setting its level to 47000 like OPL3.

Also, Doom1/2 doesn't seem to recognize OPL3 with "SET DMXOPTION=-opl3" environment variable, but it does in DOSBox and real hardware.

No, you misunderstood.
DOSBox uses OPL3 core with ANY core (Fast, Compat, Nuked) to emulate OPL2, Dual-OPL2 and OPL3.
In other words, it doesn't have special OPL2 emulation, it uses the same core as for the OPL3, so when SBPro1 is selected DOSBox simply translates the Dual-OPL2 commands to OPL3 addresses.
The only thing that might be broken is Dual-OPL2 in SBPro1 that has two independent Rhythm channels but the OPL3 has only one, and so does DOSBox has only one.
I am not sure how Sarah implemented the dbOPL core in PCem, but if it it's exactly like DOSBox, then the above statement is true.
Since PCem uses dbOPL core, NukedOPL should be used as one of the cores in OPL2 and OPL3 just like DOSBox, no separation is needed.