There's this guy over on Arokh's Lair forums that made an automated installer for Drakan that updates it with unofficial patch and a bunch of player created levels.
That would be me 😀
(...) So it has an option to install dgVoodoo, but apparently the installer's target audience tends to choose not to install it. Maybe they would if he didn't describe dgVoodoo just as a fancy way to get anti-aliasing and anisotropic filtering.
To be fair, my Drakan patch installer suggests dgVoodoo as the recommended, default option, if only the operating system supports it (and most do).
Also, it does wonders for the Level Editor's 3D View - with dgVoodoo, it's A LOT more stable, and when the 3D View crashes, it doesn't tend to also crash the Editor.
So there's no disputing that dgVoodoo is a great piece of software.
However, based on my in-game experiences (both direct ones, as well as from what the patch users have been reporting), it's at best a flawed gem.
As things stand right now, dgVoodoo is included in my Drakan patch as a sort of compromise:
On one hand, using dgVoodoo in Drakan does not come without some disadvantages (more about that below).
On the other hand, the target audience of my patch is largely computer-challenged and tends to be unwilling and/or unable to adjust their graphics card settings for best results; so using dgVoodoo is a huge boon from a deployment standpoint.
Unfortunately, I can't even begin to count the number of times I've been asked to help users disable dgVoodoo after they have installed it together with the patch (by default).
Usually it was either due to performance issues, or because of outright incompatibility with the user's hardware (eg. some integrated graphics adapters - resulting in the dreaded "couldn't find any 3D accelerator devices!" message).
Note that some time earlier, a bunch of the dgVoodoo disabling requests were also happening in part due to my carelessness in deploying the patch with anisotropic filtering enabled by default, causing blurry text - but that's been fixed since then.
In particular, at least one user who was running the patch on Linux (which is not officially supported by my patch!) reported severe performance issues when dgVoodoo was enabled; disabling it restored normal levels of performance.
Unfortunately I was unable to do anything else in that particular case - as I have effectively zero experience with Linux, as well as no machines running Linux to test the patch on.
Personally, I see no point in spending too much time ensuring native compatibility. dgVoodoo is a great piece of software and not using it with old games with modern graphics cards is just plain ignorance. Some tricks just don't work as advertised anymore natively and there are other advantages to using it.
Believe it or not - but at least on my hardware and OS (Win7), running natively (without dgVoodoo) yields both the best performance and the best visual appearance; the issues with lens flare effects notwithstanding.
I would absolutely love to be able to just deploy dgVoodoo en masse with my patch, and have it work reliably for everyone.
Sadly, it doesn't look like we're there quite yet.
Running natively has its own issues - but at least it can be counted on to work reliably, each time, every time.
At least, that's the case in Windows - remember, my patch is officially unsupported on Linux. I have put some information about running on Linux in the patch readme - but it's unofficial, and no support for it can be expected (nor will be given).
But enough about that for now.
The reason I'm here is to report 2 crippling bugs (?) which appear to be in (or at least, caused by) dgVoodoo when running Drakan.
The first bug happens when using large textures while FastVideoMemoryAccess is enabled:
I ran into this problem by sheer coincidence, when I was screwing around in the Drakan Level Editor.
I put some huge 2048x2048x32bpp textures on the landscape, to see what the practical limits are, performance-wise (quite relevant for the map I'm working on).
Those textures showed up perfectly fine in the 3D View window (which also uses dgVoodoo, but with FastVideoMemoryAccess disabled) - however, in-game, these textures appeared as black squares instead.
Disabling FastVideoMemoryAccess made those textures work properly.
They also work fine when running natively.
The 2nd bug occurs when using dgVoodoo with VRAM setting >128MB (don't remember if FastVideoMemoryAccess was enabled or not, unfortunately).
This works fine in-game when loading maps which don't use too many textures; but on texture-heavy maps (eg. Islands) some of the textures don't show up at all, and the affected terrain polys are completely transparent, as if lacking textures entirely.
It's effectively random which textures are affected; quitting the game and reloading the same map causes different textures to be missing.
Setting VRAM to 128MB or less "fixes" that problem - but it doesn't seem like much of a "fix" to me, more like a "cheap hack" at best.
Running natively, there's no such problem, even with 4GB of VRAM.
There's also a 3rd bug, which has nothing to do with the game itself - but it's quite rare and random; more-or-less impossible to reproduce.
Sometimes, dgVoodoo appears to be loading its settings from some unexpected location - despite there being a valid dgVoodoo.conf file next to the game .exe, it loads the default settings which includes the presence of the watermark.
I've experienced that issue myself at least once, as well as also saw another user experience it.
Sadly, I don't remember how we got out of that mess - highly likely it involved a reboot, though.
Finally... the dreaded "Lens Flare Effects" in Drakan.
It's such a mess, I've pretty much given up on them entirely at this point.
At one point, I wanted to use the LFEs to put a "sun" object in the sky of one of the maps - but I've long since abandoned that idea, since I hate the prospect of making a map feature dependent on a highly fickle and randomly broken graphical feature.