You can fix the colors by editing dgVoodoo.conf and setting EnumeratedResolutionBitdepths = 16. The transparency problems and missing menu backgrounds are still a huge problem though.
It seems it was working at some point in DxWnd:
https://sourceforge.net/p/dxwnd/discussion/ge … hread/8a7a55a5/
And the problems seems to be ddraw/gdi interaction and window message handling.

Well that does fix the color issues in the menus and videos, but all other issues persist. The game crashes when trying to open the D3D version in Dxwnd, so I had to write off playing it with that sorta... Except in the case of music, because Dxwnd is the only program out there with seemingly flawless CD audio emulation.

Mechanist wrote:

As per UCyborg's advice, I've tried running Drakan with DX11's software renderer (WARP) - but that doesn't work: Drakan simply complains that no 3D accelerators have been found, and refuses to launch.

A sign of running unpatched system; Platform update for Windows 7 SP1 solves this particular issue.

Mechanist wrote:

NOT visible without dgVoodoo, regardless of the "Force32BitDepthMask" seting in Arokh.ini (but they USED to be visible when that setting was set to 1, in some earlier AiO patch version).

It was renamed to "ReportFakeDepthMask".

Mechanist wrote:

EDIT: Actually, I've just found another problem with the LFE's: after an extended playing session, they cause increasing amounts […]
Show full quote

EDIT: Actually, I've just found another problem with the LFE's: after an extended playing session, they cause increasing amounts of lag - even though fast videomemory access is enabled!
Restarting Drakan then removes the lag - for a while, at least.
This is most noticeable in the Volcano level, where one particular enemy type repeatedly spams a lightning attack - which spawns about a dozen LFE's each time.
I've started to notice the problem after about half an hour of playing time, and it was starting to get unplayable (due to severe lag every time a lightning attack was used) about another half an hour later.

I messed around on Volcano level for over an hour, just reloading the save when necessary, gathering all those dragons with lightning attack to attack me for as long as possible. No lag spikes occurred.

Mechanist wrote:

So the only remaining unresolved issue for the time being is dgVoodoo sometimes randomly deciding to not load the right dgVoodoo.conf file.

Nothing random about config file loading code. The paths are determined using standard WIN32 API calls; first the location of dgVoodoo's DDraw.dll, then the location of game's executable and finally "%appdata%\dgVoodoo". First existent dgVoodoo.conf in the searched paths is used. Failure in loading due to any reason results in defaults being used.

Mechanist wrote:

To be fair, my Drakan patch installer suggests dgVoodoo as the recommended, default option, if only the operating system supports it (and most do).

I was going off the description alone when I wrote what I wrote there. So the installer default is sane only assuming the user has good enough hardware in the first place.

Mechanist wrote:

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.

Loading alternative versions/proxies of system DLLs on WINE actually requires modifying WINE configuration, otherwise defaults DLLs are loaded. D3D11 implementation there isn't exactly speedy (must also be translated to OpenGL), so with dgVoodoo you have DirectDraw-Direct3D11->OpenGL. DXVK is speedier D3D11 implementation that can be used instead, but also isn't guaranteed to work 100% as expected. GPU with Vulkan support is required for it to work at all. Older versions (0.51) have problems with lens flare effects (DXVK outputs some error about inability to map depth stencil texture), newer versions depend on features that may not be supported by the GPU.

Personally, I haven't seen what I consider normal levels of performance on Linux out-of-the-box on my PC (no dgVoodoo and DXVK), compared to Windows. Perhaps it's better with beefy CPUs. There's a real possibility some users have lower standards when it comes to performance and are happy as long as they're not running Windows.

Hi i try to play the STeam version of GTA with DG Voodoo and when i use the stretch but keep aspect ratio i have very VERY bad flickering. Any way to fix this?

(Donno if Dege is writing a list of working games) I would like to report Kondom Elemental (DX7) working with DGVoodoo2.

UCyborg wrote:

It was renamed to "ReportFakeDepthMask".

But wait - shouldn't the new setting name appear in Arokh.ini the first time Drakan is started after applying the new AiO patch?

I'm still on AiO 153 as of right now, BTW.
I'll be releasing the new CP build (with the newest AiO version) around Xmas.

UCyborg wrote:

I messed around on Volcano level for over an hour, just reloading the save when necessary, gathering all those dragons with lightning attack to attack me for as long as possible. No lag spikes occurred.

Actually I think the real cause wasn't the bone dragons, but those blasted "Dark Knights" who throw the lightning attack thing. It branches out a lot, and results in a lot of separate flares (at least a dozen instances) showing on the screen at the same time.
Maybe it's something specific to my hardware setup; I don't know.

Also, perhaps you misunderstood what I meant - it wasn't just a regular case of lag spikes occuring when the lens flares are visible: IIRC it was noticeably laggy all the time, even when no new lens flares were being generated (eg. after going back to the starting area of the level, which has long since been cleared out of all enemies).

UCyborg wrote:

Nothing random about config file loading code. The paths are determined using standard WIN32 API calls; first the location of dgVoodoo's DDraw.dll, then the location of game's executable

In this case, those 2 paths are one and the same: DDraw.dll is in the same folder as Drakan.exe; the .conf file is also there.

UCyborg wrote:

and finally "%appdata%\dgVoodoo". First existent dgVoodoo.conf in the searched paths is used.

I have the exact same .conf file in %appdata%\dgVoodoo, so it couldn't have been loading it from there, either.

UCyborg wrote:

Failure in loading due to any reason results in defaults being used.

Yes - but why does it fail to load an existing, perfectly accessible file from 2 completely different, unrelated locations?
That's the "random" part I was referring to.

I wouldn't be surprised if that was another strange bug in the WINAPI; not after seeing KERNEL32.GetProcAddress mysteriously fail for no reason at all - yet in a perfectly consistent, repeatable fashion.

Incidentally, this settings loading issue happened to another Drakan player just yesterday. Again, overwriting the dgVoodoo .dll files with the newest version "fixed" the problem... for now.
Next time it happens to me, I'm attaching a debugger and seeing where the file load fails. I've had enough of this configuration loading fail nonsense by now.

If I can't track it down, then the next obvious course of action will be to add some code to my patch that patches dgVoodoo's hardcoded fallback defaults with the correct settings at runtime.
No, I am not easily deterred.

Really, in that case, I would rather just edit the binaries directly - but I'm pretty sure that this would run afoul of dgVoodoo's license, or some other legal stuff. So I'll just patch the memory image of the files at runtime, to avoid any such issues.

EDIT: I poked around a bit in the code, and I did not like what I saw there:
Using dgVoodoo 2.55 with the dgVoodoo.conf from 2.55.3 seems to replicate the symptoms of the issue quite reliably; that was my first clue that something is very wrong.

As it turns out, the dgVoodoo.conf parser appears to be quite poorly written - in that encountering any setting names it does not understand seems to cause the entire file parsing attempt to fail.
In this case, one of the cuplrits was the "Environment" value in "GeneralExt", since dgVoodoo 2.55 does not recognize that as a valid setting.

Even worse - when the file parsing attempt fails, it fails silently - leaving the user with no indication whatsoever that there is any problem to begin with!
The only sign of trouble is that the dgVoodoo watermark inexplicably shows up, even though it has been disabled by the user - but what the user does not know, is that ALL of their remaining dgVoodoo settings are also getting ignored!
Now, that itself reeks of poor design and looks like a flashing red warning light at the end of a dead-end tunnel, as far as deployment is concerned - but it doesn't really get me any closer to the root of the problem.

The problem lies somewhere much deeper; since I know for a fact that this "settings loading bug" tends to happen even to players who have not been messing around with the dgVoodoo.conf file at all (outside of using the supplied control panel, which should be perfectly fine and not break things!).

So in the end, once again I've wasted a lot of time with nothing useful to show for my efforts.
The only "good" thing is that I've got a pretty good understanding of how the file parsing works now, and where the "hardcoded defaults" are stored in the DDraw.dll.

UCyborg wrote:

(some Linux stuff)

It was quite a while ago, and I don't remember what was happening there exactly.
Also you'll have to excuse me for not being able to provide any proper support for Linux, since I don't even know anything about it to begin with. In the case of my patch, it's a strictly "You're on your own here, buddy" kind of thing.

It is very possible that what you described was the case there, though.

Incidentally - if I understand this right, it should be "safe" to have my patch installer add those registry entries at install time, even on Windows machines?
Since to the best of my understanding, Windows will just ignore those registry values entirely.

Reporting Project I.G.I as working with DGVoodoo2

Outlaws crashes with high display resolutions

FulValBot wrote:

Outlaws crashes with high display resolutions

High as in?

2880x2160 works.

1920x1080

this when Direct3d is enabled, i don't know with glide and directdraw

(that resolution it was selected into dgVoodoo2)

FulValBot wrote:

1920x1080

this when Direct3d is enabled, i don't know with glide and directdraw

(that resolution it was selected into dgVoodoo2)

1920x1080 forced resolution (though why would you distort aspect ratio? Outlaws is 4:3 only) in dgVoodoo works fine here with the Direct3D render.

There is an option that fit screen, so it was 4:3

Reporting Jack The Ripper: New-York 1901 (DX8) working with DGVoodoo2, force resolution partly working (playscreen remaining small)

Hello Guys, has anyone got Summoner to run with DGVoodoo2 in DX mode yet ? (Game cant find Video Card when using DGVoodoo2)

Some versions of The Summoner do work:
Re: dgVoodoo 2 for DirectX 11
Fairly sure I tested the GoG version.

thanks, i saw that posting, but wasnt able to achive anything. I have the retail version on DVD and the setup doest even find the D3D wrapper. Couldnt find any references either 🙁
The game stores settings in the registry, tried to mess with the card drivers settings but also no luck.

The trick could be a proper setting under HKCU\Software\Volition\Summoner\Video Card 0 , with nothing or improper settings sum.exe always loads Glide.
BTW. The glide wrapper properly recongnizes "dgVoodoo Virtual 3D Accelerated" using the launcher glide device search (summoner.exe) , only not the D3D device.

Summoner works in glide mode but not with dx mode of dgvoodoo.
RJ8 was asking about dx mode.
ZellSF had it running in glide mode.

robertmo wrote:

Summoner works in glide mode but not with dx mode of dgvoodoo.
RJ8 was asking about dx mode.
ZellSF had it running in glide mode.

No I ran it in DX mode.

Retail copy works too, if you patch it.

Though you should have been able to find references to Voodoo in the unpatched Sum.exe file.

Doesn't seem to be any point though? The resolution patch doesn't support widescreen.

Both patched (1.4) and unpatched games require renaming first voodoo word in sum.exe

Card autodetection in summoner.exe's setup doesn't work for dgvoodoo's direct x.
So just detect it with dgvoodoo files removed.

Thanks for catching up on this, but what exactly do i have replace/rename with what in the sum.exe ?