This game was very tough.
What I came to is:
1) discovered (at least, for me it was new) the rendering technique of this game, but I guess it's established custom for all ones working with static background with z-buffers.
Depth map of the background isn't a real depth buffer that the game artist(s) pre-baked somehow. Instead, the particular regions (on per pixel basis) of the background are just classified into a few depth-categories: say, very near, near, middle, far and very far.
When the real z-buffers are generated then those "classifying indices" are replaced (from a lookup table) with a real z-buffer value.
Well, the interesting part is: Where do those real z-values come from? The game doesn't leave it to chance. Instead, at startup, it renders some (or various) scanlines into the z-buffer by the 3D hw itself then reads back the concrete values for later usage (content of the lookup table).
In other words, mapping of an abstract z-value in the [0..1] domain to a 16 bit z-buffer value is done by the GPU itself.
The game does some trivial checkings for the values read back, to see if accessing z-buffer is really working and make sure that not just some waste values it got back.
If the checks don't pass then 'DX initialization error' message comes.
2) I found an ugly copy-paste bug in dgVoodoo, that's why it didn't worked at all without fast vidmem access (independently on output API).
Also, I encountered another one when the DX debug layer broke the game: ironically, it affected only the most common and simple case: FL10.1 without resolution and MSAA forcing. I fixed it too.
3) However, due to the technique used for generating the z-buffer values, the game is very very sensitive to forced resolution and MSAA.
If any of them is forced then none of the rendered scanlines will be per-pixel accurate and so the game will work with corrupted z-values.
I patched the game to try to make it compatible with forced res and MSAA.
For forced res, I modified the lookup-table-filler game code to read from the z-buffer from a location of 1-2 pixels away. This seems to work.
For MSAA I modified the scanline drawer code to use pixel coordinates offseted by -0.5 to avoid blurring neighbored lines, but it doesn't work. The game stomach 2x MSAA but not higher.
For FL 10.0, forced MSAA doesn't work at all ('DX init failed' error message) because dgVoodoo cannot provide CPU-access for a z-buffer at this level, so that's normal.
Also, when resolution is forced then there are some glitches around the animated characters. So, the game can only be rendered perfectly if none of the resolution and MSAA is forced. 🙁
Now I guess that Drunna Morbus Gravis suffers from the same problem.