Reply 3820 of 3952, by Mechanist
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).