Far Cry 1 problem has been solved with this -> https://github.com/CookiePLMonster/SilentPatc … FarCry/releases

but we can test dege's dll too!

lowenz wrote:

Far Cry 1 problem has been solved with this -> https://github.com/CookiePLMonster/SilentPatc … FarCry/releases

but we can test dege's dll too!

Cool. Thanks. This ,the widescreen patch from AG 13 and 4k all max makes the game Unreal. 😀

Yeah, you can CHAIN the patches (SilentPatchFarCry.asi is compatible with 13AG widescreen fix, just put "SilentPatchFarCry.asi" in the bin32/64 folder along 13AG fix) and you got the landmass reflections and the working VSync back 😀

In the end i managed to run ZDoom with DXGL, dgVoodoo 2 didn't work.

dondiego wrote:

I've tried the latest version (2.55.4) with ZDoom 1.23b33 and it doesn't work. I get a "DirectDraw returned no display modes" error. Same with WineD3D for windows. I'm on Windows 8.1 32 bits.
https://zdoom.org/files/123beta33.zip

How can I install it? If I just launch it then I get an error message about missing .wad file.

http://www.pc-freak.net/files/doom-wad-files/Doom1.WAD

Edit: ZDoom 1.23 Beta 33 works on my end (Windows 10 1803), the only issue I noticed with dgVoodoo is switching from fullscreen to windowed mode results in the blackness. Doesn't work bad natively neither (at least if you avoid alt-tabbing), just have to disable maximized windowed mode to get rid of the borders. Windows 8.x systems also have issue with bad performance unless this is disabled.

Blade Runner crashes on the last few versions of the wrapper.

I use it in conjunction with the modern fix for the gamer and it has never failed until recent versions.

SO i've been testing the Fighters Trilogy by Jane's with the latest DGvoodoo2 and FA database patches
http://jkpeterson.net/fa/index.php

-USNF'97 works fine but it has slow cursor menus, the game runs well too, but a bit fast in missions.

-Advanced Tactical Fighters GOLD Works fine too, same errors as above but the game speed is great!, using the Patch 2

-Jane's Fighters Anthology, as i Said it Before, its plagued with black screen menus that goes away if you move the mouse all over the screen, and the game flickers with black stripes during missions, DgVoodoo2 Enables Compatibility with Stream and Origin Overlay, something that the 2 above doesn't.

all 3 games uses the same engine, but only FA has this problem

Just dropping in to say that Hydro Thunder works amazingly with dgVoodoo 2. Now I can run the game at max resolution instead of 640x480 resolution.

Hi!

UCyborg wrote:

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 😀

UCyborg wrote:

(...) 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.

UCyborg wrote:

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.

Please help me. Clive Barker's Undying crashes in resolution more than 1600*1200. As example 2650*1440.
General GLVoodoo 2.55.4 settings:
Output API - Best available or D3D 11 (10.1)
Adapter to use: GTX 1070
Full screen output: default
Capture mouse - disabled.
All other settings by default.

DirectX settings:
Vram 1024 mb (no possibility to increase this value, game monitoring by RivaTunerStatisticServer shows 1300 mb of vram usage)
Fast memory access enabled (with disabled situation is the same).
All other settings by default.

Set 128 MB for ALL Unreal Engine 1 games 😉

lowenz wrote:

Set 128 MB for ALL Unreal Engine 1 games 😉

Did not help. Set 128 MB. Flies both with the Widescreen patch, and without. Up to 1600 * 1200 does not crash. In 1920 * 1080 are bit rare. B 2560 * 1440 - 100% reproducibility.
I attach a save game, simply unpack it in the slot for saves and go forward along the corridor, go down the stairs to the gallery with large windows and a ghost, at the end of the stairs - game crashes.

Inqizitor wrote:

lowenz wrote:

Set 128 MB for ALL Unreal Engine 1 games 😉

Не помогло. Поставил 128 мб. Вылетает как с Widescreen патчем, так и без. До 1600*1200 не вылетает. В 1920*1080 бывают но редко. В 2560*1440 - 100% воспроизводимость.
Прикрепляю сейв, просто распаковать в слот для сейвов и пройти вперед по коридору, спуститься по лестнице вниз в галерею с большими окнами и призраком, в конце лестницы - вылет.

English only, if you please... we don't have any Russian moderators. 😀

Stiletto wrote:

English only, if you please... we don't have any Russian moderators. 😀

I'm sorry. I've edited a bit my previous post.

Inqizitor wrote:

lowenz wrote:

Set 128 MB for ALL Unreal Engine 1 games 😉

Did not help. Set 128 MB. Flies both with the Widescreen patch, and without. Up to 1600 * 1200 does not crash. In 1920 * 1080 are bit rare. B 2560 * 1440 - 100% reproducibility.
I attach a save game, simply unpack it in the slot for saves and go forward along the corridor, go down the stairs to the gallery with large windows and a ghost, at the end of the stairs - game crashes.

Works fine for me.

Crashes here, but also does the same natively (with this of course...) and with the Glide render running under nGlide. So probably a game engine issue and not a dgVoodoo issue.

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).

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).

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.

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.