dgVoodoo 2 for DirectX 11

General information and assistance with dgVoodoo.

Re: dgVoodoo 2 for DirectX 11

Postby Mechanist » 2018-11-02 @ 17:11

I've been digging around, trying to consistently replicate the graphical problems in Drakan.
Also trying to figure out what's going on with the blasted lens flare effects.

Here's what I found.

NOTE: all testing was done using AiO patch version 153; Community Patch version 153.01 (although using the CP should not matter in this case, since in 153.01 there are no other DLL fixes beyond the AiO patch).
Test machine: AMD FX-8370, 32GB RAM, 2x MSI Radeon R7 260x GPU (CrossFire disabled for Drakan), AMD 990FX chipset. Tested under Windows 7 x64; 18.4.1 graphics driver version.
Settings: 1920x1200x32bpp resolution, 60Hz, Drakan graphical options all maxed out; dgVoodoo set to 2xAA, 1024MB VRAM, no resolution forcing.

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.


Lens flare effects:
  • VISIBLE with dgVoodoo - but there's a lot of lag when they are onscreen and fast videomemory access is disabled (no lag or FPS drops when fast videomemory access is enabled, though),
  • 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).

Now the problem with lens flare effects is that Drakan seems to randomly decide that the "draw lens flares" setting in Drakan.cfg should be disabled (and resets it to "0"), when in fact it's been previously enabled by the user.
Not sure what causes that; unfortunately I haven't been able to consistently reproduce the issue; outside of the fact that it's happened to me at least 3 times already.

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.


Texture loading problems: now this is interesting, because I was entirely unable to reproduce them - even despite reloading the exact same level file(s) in which I have first observed those problems.
I've tried 4 different dgVoodoo versions, from 2.55 to 2.55.4; couldn't get this to show up again on any of them.

UCyborg's also tried to reproduce the problem, to no avail.

The only similar issue I've observed was in the Editor's 3D View: when I had a debugger attached to it, if a breakpoint was hit during the texture loading process, the textures would always load completely black, all of them (this was with dgVoodoo enabled).

At this point, I'm left to conclude that those texture loading problems must have been some bizarre artifact of the OS state becoming corrupted due to extensive uptime combined with all the application crashes.
(I restart Windows very infrequently - normally only when its state becomes so messed up that further usage is completely impossible)


So the only remaining unresolved issue for the time being is dgVoodoo sometimes randomly deciding to not load the right dgVoodoo.conf file.
It happened to me today when I reverted back to dgVoodoo 2.55 while attempting to recreate the texture loading bug; but I didn't attempt to track the problem down any further. Don't feel like trying to debug a 3D API that I don't have the source code for (and I know I won't, so that wasn't even a question).
Last edited by Mechanist on 2018-11-03 @ 06:58, edited 1 time in total.
User avatar
Mechanist
Newbie
 
Posts: 3
Joined: 2018-10-28 @ 19:53

Re: dgVoodoo 2 for DirectX 11

Postby Inqizitor » 2018-11-02 @ 22:48

ZellSF wrote:Inqizitor: I would recommend setting the game resolution to 1280x720 and the dgVoodoo resolution in dgVoodooCpl.exe to 2560x1440. The game will then render in 2560x1440, the UI will just be a bit larger (which is better IMO).

Thank you, it works fine. Also I've forced AF and AA and no crashed during game.
Inqizitor
Newbie
 
Posts: 4
Joined: 2018-10-31 @ 17:37

Re: dgVoodoo 2 for DirectX 11

Postby alberthamik » 2018-11-04 @ 04:25

Testing out a rather clunky Descent clone from 1998 called Adrenix. This game has issues running properly in it's D3D render mode in modern Windows, and while it does open with the current version of dgvoodoo, it has graphical issues everywhere. The smacker videos play either distorted or in a 2-bit color format, the main menus are rainbow colored 256 garbage or not refreshing with a purple hue (bit hard to explain without recording that latter instance), and ingame many HUD elements are just black. It has a software renderer but that has some issues too, unrelated to dgvoodoo. The D3D renderer w/o dgvoodoo will post error messages trying to load smacker vids, but will open them only w/ the same issues as mentioned before, and ingame the UI stuff renders fine but many world textures render as transparent if black and other miscellaneous issues.
alberthamik
Newbie
 
Posts: 8
Joined: 2017-7-09 @ 13:08

Re: dgVoodoo 2 for DirectX 11

Postby ZellSF » 2018-11-04 @ 16:25

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/discuss ... /8a7a55a5/
And the problems seems to be ddraw/gdi interaction and window message handling.
ZellSF
Oldbie
 
Posts: 1200
Joined: 2006-1-01 @ 18:19

Re: dgVoodoo 2 for DirectX 11

Postby alberthamik » 2018-11-04 @ 20:19

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.
alberthamik
Newbie
 
Posts: 8
Joined: 2017-7-09 @ 13:08

Re: dgVoodoo 2 for DirectX 11

Postby UCyborg » 2018-11-05 @ 01:49

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 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.
UCyborg
Member
 
Posts: 244
Joined: 2015-9-04 @ 11:10

Re: dgVoodoo 2 for DirectX 11

Postby Glurak » 2018-11-10 @ 04:20

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?
Glurak
Newbie
 
Posts: 21
Joined: 2015-1-06 @ 15:51

Re: dgVoodoo 2 for DirectX 11

Postby RJ8 » 2018-11-10 @ 16:03

(Donno if Dege is writing a list of working games) I would like to report Kondom Elemental (DX7) working with DGVoodoo2.
RJ8
Newbie
 
Posts: 57
Joined: 2016-4-14 @ 15:56
Location: Germany

Re: dgVoodoo 2 for DirectX 11

Postby Mechanist » 2018-11-10 @ 18:14

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.
User avatar
Mechanist
Newbie
 
Posts: 3
Joined: 2018-10-28 @ 19:53

Re: dgVoodoo 2 for DirectX 11

Postby RJ8 » 2018-11-15 @ 11:28

Reporting Project I.G.I as working with DGVoodoo2
RJ8
Newbie
 
Posts: 57
Joined: 2016-4-14 @ 15:56
Location: Germany

Re: dgVoodoo 2 for DirectX 11

Postby FulValBot » 2018-11-18 @ 22:31

Outlaws crashes with high display resolutions
FulValBot
Newbie
 
Posts: 28
Joined: 2008-3-01 @ 18:43

Re: dgVoodoo 2 for DirectX 11

Postby ZellSF » 2018-11-18 @ 22:35

FulValBot wrote:Outlaws crashes with high display resolutions

High as in?

2880x2160 works.
ZellSF
Oldbie
 
Posts: 1200
Joined: 2006-1-01 @ 18:19

Re: dgVoodoo 2 for DirectX 11

Postby FulValBot » 2018-11-18 @ 23:03

1920x1080

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

(that resolution it was selected into dgVoodoo2)
FulValBot
Newbie
 
Posts: 28
Joined: 2008-3-01 @ 18:43

Re: dgVoodoo 2 for DirectX 11

Postby ZellSF » 2018-11-18 @ 23:11

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.
ZellSF
Oldbie
 
Posts: 1200
Joined: 2006-1-01 @ 18:19

Re: dgVoodoo 2 for DirectX 11

Postby FulValBot » 2018-11-18 @ 23:13

There was an option selected to fit screen, so it was 4:3
FulValBot
Newbie
 
Posts: 28
Joined: 2008-3-01 @ 18:43

Previous

Return to dgVoodoo General

Who is online

Users browsing this forum: No registered users and 1 guest