VOGONS


dgVoodoo 2 for DirectX 11

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 3580 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

Miko-san's Miracle Board has severe z-fighting issues. Works fine in WineD3D 2.2, but not later WineD3D versions or natively. I would consider it unplayable in dgVoodoo2.

Unknown 2018-05-09 19-32-48-96.jpg
Filename
Unknown 2018-05-09 19-32-48-96.jpg
File size
294.75 KiB
Views
4099 views
File license
Fair use/fair dealing exception

I Was An Atomic Mutant also has some minor z-fighting issues, but it doesn't work with any other wrappers so I can't check if there's any circumstances where the game runs "correctly". Works great with resolution forcing though (usually supports max 1024x768):

Mutant 2018-05-08 21-15-06-90.jpg
Filename
Mutant 2018-05-08 21-15-06-90.jpg
File size
404.72 KiB
Views
4099 views
File license
Fair use/fair dealing exception

Cold Zero: The Last Stand Demo (I couldn't get the full game to run) has some issues with lightning, here's native:

ColdZero 2018-05-09 22-02-19-39.jpg
Filename
ColdZero 2018-05-09 22-02-19-39.jpg
File size
112.4 KiB
Views
4099 views
File license
Fair use/fair dealing exception

And here's dgVoodoo2, where it should be obvious something is missing:

ColdZero 2018-05-09 22-04-33-68.jpg
Filename
ColdZero 2018-05-09 22-04-33-68.jpg
File size
104.2 KiB
Views
4099 views
File license
Fair use/fair dealing exception

Mage Bros has a problem with the firing projectile. It should not have black squares (no issue natively). To run it (and Hopmon) I also had to hex edit the exe to point to dgdraw.dll and rename dgVoodoo2 to dgdraw.dll.

MageBros 2018-05-09 19-13-44-11.jpg
Filename
MageBros 2018-05-09 19-13-44-11.jpg
File size
631.54 KiB
Views
4099 views
File license
Fair use/fair dealing exception

The Lord of the Rings: The Fellowship of the Ring crashes at start. It works natively if you use 3DAnalyze's "LOTR texture fix", but I believe dgVoodoo's issue with the game is something else.

I also tried Beast Wars: Transformers. I think it has a compatibility issue with dgVoodoo2, but this game is just a PITA to deal with in multiple ways. I wouldn't look into it unless you're prepared for a headache (and it's a pretty bad game too).

Last edited by ZellSF on 2018-05-09, 20:51. Edited 6 times in total.

Reply 3581 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

Hopmon is from the same developer as Mage Bros and might share the same engine, but at the start it looks to have no rendering issues and resolution forcing is a nice bump for this art style (the game is usually limited to low resolutions):

Hopmon 2018-05-09 19-10-01-28.jpg
Filename
Hopmon 2018-05-09 19-10-01-28.jpg
File size
566.72 KiB
Views
4097 views
File license
Fair use/fair dealing exception

Kurukuru UFO works great. It's a simple 2D ddraw game so that shouldn't be a surprise, but Windows native ddraw fails. dgVoodoo2 can be used for some integer scaling if desired:

UFO 2018-05-09 00-12-45-91.png
Filename
UFO 2018-05-09 00-12-45-91.png
File size
247.89 KiB
Views
4097 views
File license
Fair use/fair dealing exception

D.O.G: Fight For Your Life also runs great. Software rendered 3D though so no sense in resolution forcing, you could do integer scaling if you want:

DUNE 2018-05-08 22-33-22-03.png
Filename
DUNE 2018-05-08 22-33-22-03.png
File size
63.96 KiB
Views
4097 views
File license
Fair use/fair dealing exception

A.I.M. Artificial Intelligence Machine will switch to windowed mode in mission briefing and won't be able to recover if you go to options (separate program). Runs great though and resolution forcing helps with bad UI scaling (though worryingly I had one render crash in a relatively short testing period):

AIM 2018-05-09 19-46-27-99.jpg
Filename
AIM 2018-05-09 19-46-27-99.jpg
File size
755.65 KiB
Views
4097 views
File license
Fair use/fair dealing exception

Daemon Vector works pretty much perfectly. Usually limited to 800x600, here it is running at higher than that:

DaemonVector 2018-05-09 18-41-56-79.jpg
Filename
DaemonVector 2018-05-09 18-41-56-79.jpg
File size
474.98 KiB
Views
4097 views
File license
Fair use/fair dealing exception

Reply 3582 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

Technomage works perfectly. PSX port, so 3D rendering is ugly and you might not want to force resolution (from the default 640x480) and see it clearer, plus it breaks text rendering slightly.

Technomage 2018-05-10 13-05-38-62.jpg
Filename
Technomage 2018-05-10 13-05-38-62.jpg
File size
435.74 KiB
Views
4044 views
File license
Fair use/fair dealing exception

Tenerezza just looks beautiful with dgVoodoo2, usually restricted to 640x480. Only runs at 30 FPS though, which seems weird, but it's the same natively.

Tenerezza 2018-05-10 13-49-10-55.jpg
Filename
Tenerezza 2018-05-10 13-49-10-55.jpg
File size
445.33 KiB
Views
4044 views
File license
Fair use/fair dealing exception

Wanted: Dead or Alive is another perfectly working game (natively rendering is broken). Usually limited to low resolution.

Wanted 2018-05-10 11-55-10-05.jpg
Filename
Wanted 2018-05-10 11-55-10-05.jpg
File size
614.27 KiB
Views
4044 views
File license
Fair use/fair dealing exception

Wanted: A Wild Western Adventure is really crashy on newer computers and I didn't bother to figure out why, but it's the same natively as with dgVoodoo2. Antialiasing creates some artifacts, so off in the screenshot. Has good support for high-resolution natively, so no use for resolution forcing.

PICTuRE 2018-05-10 12-47-44-60.jpg
Filename
PICTuRE 2018-05-10 12-47-44-60.jpg
File size
294.7 KiB
Views
4044 views
File license
Fair use/fair dealing exception

Arcturus - The Curse and Loss of Divinity seems to have no issues. Resolution forcing and MSAA makes dialogue boxes look really bad, so some SMAA injector (any plans for SMAA support in dgVoodoo2?) is needed. I want to play this later, so I didn't enable integer scaling since it would probably not work with SMAA injectors, so here's the game running at 1280x720 scaled to 2560x1440 by dgVoodoo2:

ArcExe 2018-05-10 19-56-43-15.jpg
Filename
ArcExe 2018-05-10 19-56-43-15.jpg
File size
855.68 KiB
Views
4003 views
File license
Fair use/fair dealing exception

Reply 3583 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Mmm... thanks for that, again! 😎

ZellSF wrote:

Miko-san's Miracle Board has severe z-fighting issues. Works fine in WineD3D 2.2, but not later WineD3D versions or natively. I would consider it unplayable in dgVoodoo2.

I don't know why 16 bit z-buffers behave so badly in some games, but I feel the implementation of forced 24 bit depth buffers would come in handy.
Patterned after the 32 bit rendering for color buffers with some options like dithering: ("app driven", "force24bit").

Reply 3584 of 3949, by antrad

User metadata
Rank Member
Rank
Member

I see ZellSF is posting a lot of games. Is there a compatibility list somewhere ? I played around 10 games with dgVoodoo 2 so far from start to finish, but I just post about it on PCGamingWiki pages if dgVoodoo fixes a game, or if it can improve it in some way(resolution, HUD scaling, etc).

https://antonior-software.blogspot.com

Reply 3586 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

GTOK The Defender is flawless. Game natively supports high resolution and hor+ widescreen, though the UI scaling is bad. Screenshot is the UI at 1280x720 size, so you can imagine how small it is at 1440p and 4K.

gtok 2018-05-10 23-20-15-13.jpg
Filename
gtok 2018-05-10 23-20-15-13.jpg
File size
370.81 KiB
Views
3905 views
File license
Fair use/fair dealing exception

Another game from the same series (which comes in tiny adorable half-size CD cases that I almost want to collect all of), Turbo Toons is different, only supports 640x480. Also seems to have some colorkeying problems, but considering it looks the same natively and these are extremely low budget games, I'm going to attribute it to the game not dgVoodoo2. The art style is a perfect fit for resolution forcing.

tt 2018-05-10 23-31-06-26.jpg
Filename
tt 2018-05-10 23-31-06-26.jpg
File size
389.7 KiB
Views
3905 views
File license
Fair use/fair dealing exception

Galidor - Defenders of the Outer Dimension works perfectly, needs RTTexturesForceScaleAndMSAA=false for AA and/or forced resolution, though it has native high resolution support. Widescreen is vert- and really not recommended

Galidor 2018-05-11 17-59-18-36.jpg
Filename
Galidor 2018-05-11 17-59-18-36.jpg
File size
389.57 KiB
Views
3905 views
File license
Fair use/fair dealing exception

Desert Law is a simple 2D game, so no dgVoodoo2 enhancements. Can't even do integer scaling because it messes with the mouse, but the game works as it should.

Game 2018-05-11 19-31-45-25.jpg
Filename
Game 2018-05-11 19-31-45-25.jpg
File size
436.51 KiB
Views
3905 views
File license
Fair use/fair dealing exception

DeathKeep is software rendered 3D, but dgVoodoo2 can help with integer scaling.

DK 2018-05-11 18-33-26-26.png
Filename
DK 2018-05-11 18-33-26-26.png
File size
65.81 KiB
Views
3905 views
File license
Fair use/fair dealing exception

Reply 3587 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

Angels vs Devils is a DllMain game, so doesn't work.

DeathDrome has flickering graphics. Works fine in DxWnd.

ExcaliBug crashes when initializing the 3D render (load screen shows up fine). Works natively. There's a demo here: https://www.gamepressure.com/download.asp?ID=305

antrad wrote:

I see ZellSF is posting a lot of games. Is there a compatibility list somewhere ?

Sort of hard to get compatibility lists going considered how spread the PC gaming community is when it comes to languages. Plus PC has more complicating factors than console emulators (so many different software/hardware setups), now dgVoodoo2 doesn't have many software/hardware specific issues, but if someone writes that game X works with dgVoodoo2 on a compatibility list, it's going to be really annoying if they don't also write down how to get game X to work at all.

Ideally such a thing would be worked into the PC Gaming Wiki. Don't see it happening though.

Reply 3588 of 3949, by VicRattlehead

User metadata
Rank Newbie
Rank
Newbie
ZellSF wrote:

I Was An Atomic Mutant also has some minor z-fighting issues, but it doesn't work with any other wrappers so I can't check if there's any circumstances where the game runs "correctly". Works great with resolution forcing though (usually supports max 1024x768):

I had trouble getting this game to work correctly.

At first the monster model wouldn't display at all with or without dgVoodoo2. I tried the demo and that didn't have the same problem. I experimented with different settings, compatibility options, etc. Finally, I renamed the .exe and that fixed the problem. This is probably the fault of ATI's attempt at applying compatibility.

Reply 3589 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t
VicRattlehead wrote:
ZellSF wrote:

I Was An Atomic Mutant also has some minor z-fighting issues, but it doesn't work with any other wrappers so I can't check if there's any circumstances where the game runs "correctly". Works great with resolution forcing though (usually supports max 1024x768):

I had trouble getting this game to work correctly.

At first the monster model wouldn't display at all with or without dgVoodoo2. I tried the demo and that didn't have the same problem. I experimented with different settings, compatibility options, etc. Finally, I renamed the .exe and that fixed the problem. This is probably the fault of ATI's attempt at applying compatibility.

Yeah that's the native behavior on a Nvidia GPU too (though I didn't have to rename the file when using dgVoodoo2).

Reply 3590 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

Dungeon Master Return to Chaos (fan port of Dungeon Master / Chaos Strikes Back / Skullkeep) doesn't natively support any resolution other than 640x400, so dgVoodoo2 can help a lot with scaling, sadly the first integer scale for 640x400 is 3200x2400 and who has a monitor that can display that without distortion?

RTC 2018-05-12 12-30-36-93.png
Filename
RTC 2018-05-12 12-30-36-93.png
File size
82.96 KiB
Views
3837 views
File license
Fair use/fair dealing exception

GROM: ...Terror in Tibet! is by Rebelmind, the people who made Chosen Well of Souls, so probably using similar tech and not so surprising that it works in dgVoodoo2. At launch this was criticized quite a bit for only supporting 800x600, dgVoodoo2 can go quite a bit higher but texture filtering creates artifacts and the 2D assets do not look good unfiltered at high resolution.

grom 2018-05-12 13-22-37-11.jpg
Filename
grom 2018-05-12 13-22-37-11.jpg
File size
760.84 KiB
Views
3837 views
File license
Fair use/fair dealing exception

For their next game Rebelmind supported high resolution quite nicely. Widescreen is hor+ with UI stretch.

main 2018-05-12 13-26-05-79.jpg
Filename
main 2018-05-12 13-26-05-79.jpg
File size
673.53 KiB
Views
3837 views
File license
Fair use/fair dealing exception

Chaos Legion is interesting:

ChaosLegion 2018-05-12 19-06-38-02.jpg
Filename
ChaosLegion 2018-05-12 19-06-38-02.jpg
File size
93.45 KiB
Views
3807 views
File license
Fair use/fair dealing exception

Yes those textures are all wrong. They are the same natively and in WineD3D, but there is a fix here (I can email it to you if you want) that makes it look like it's supposed to and it is a D3D8.dll file implicating it might be a D3D8 related problem.

ChaosLegion 2018-05-12 19-03-50-04.jpg
Filename
ChaosLegion 2018-05-12 19-03-50-04.jpg
File size
90.2 KiB
Views
3807 views
File license
Fair use/fair dealing exception

Reply 3591 of 3949, by ZellSF

User metadata
Rank l33t
Rank
l33t

About Chaos Legion:

ducon2016 wrote:

Yes of course, happy to share, and dgVoodoo2 could do that without a problem. I just round the height of the textures to the next power of 2 in the CreateTexture method. For example if the height is 41, I change it to 64 when the texture is created. If already a power of 2, I do not change anything.

Stealth Combat: Ultimate War crashes on start (after failing to play some movies that play in a separate window), natively (and WineD3D) does the same (except movies work natively) . DxWnd works though.

Torrente is another DllMain game.

The Guardian of Darkness works, usually a fixed resolution game.

game 2018-05-12 23-48-41-08.jpg
Filename
game 2018-05-12 23-48-41-08.jpg
File size
204.86 KiB
Views
3768 views
File license
Fair use/fair dealing exception

Wars and Warriors - Joan of Arc can usually only be played in two resolutions, either 1024x768 (game resolution) or 1920x1080 (fan patch), the latter isn't entirely perfect. with dgVoodoo2 you can run any resolution you want, though since the game doesn't support multiple resolutions the UI is still locked at those respective sizes. Texture filtering is fine, antialiasing creates (minor) artifacts. This is 4K downsampled to 1440p:

joan 2018-05-13 14-38-48-51.jpg
Filename
joan 2018-05-13 14-38-48-51.jpg
File size
1.2 MiB
Views
3721 views
File license
Fair use/fair dealing exception

Reply 3592 of 3949, by UCyborg

User metadata
Rank Member
Rank
Member

Any news on Drakan's lens flare effects? It's practically unplayable when breathing fire with the dragon, FPS dips down to 10. For some reason, that's another example of a problem where experience with dgVoodoo just goes crappier with higher resolutions.

What's even more bizarre...I tried the game on Windows XP x64 with latest NVIDIA drivers for that OS, and the effects rendered maybe one time time out of ten. Restarted the game many times, flipped various graphics settings, I have no idea why they worked maybe 2 times in total. It was pretty random. When they did work, there were no frame drops.

Another strange thing on XP, pausing the game would result in big FPS drop, making the mouse cursor choppy, which only occurred in fullscreen mode. Windowed mode was fine. On NT 6.x OSes, this happens natively (regardless of fullscreen/windowed) only if you force MSAA. Seems to be NVIDIA specific thing. I believe the patch that restores menu background functionality also has something to do with it. No background, no extra processing I guess.

PS: There's at least one player-created level (Dragon Sea of Fire & Storm), where the FPS is constantly low while lens flare effects are enabled. It can be unpacked with 7-Zip to "Drakan\Multiplayer\Air\Dragon Sea".

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 3593 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Thanks for the extra level to try!
I've just tested it through developer mode with bump mapping/trilinear filtering/lens flare etc. enabled but I didn't get FPS dropdowns.
Aside from some temporal and minor fallback I got constant 60 fps in 4K without MSAA enabled, didn't matter if I breathed fire or saw the lens flares.

Two facts though, they may make a difference:
- I still run the exe last time I sent you with the screenshot-save patch
- I chosed 1280x1024 32bit ingame and forced the resolution to max (4k) from dgVoodoo.

Doesn't have the game some sort of 'console text prompt' or sg like that? Those are typical framerate killers (like it was in KQ8) when shown because of locking the backbuffer for direct CPU access each frame.
Best would be to patch Drakan to be compatible with fast vidmem access. Once I debugged out that Drakan reads cursor bitmap through ReadFile directly to the mapped area of its texture.
I think it's matter of the code rewritten by inserting a temporary area with a memory copy. I'll try to dig out that code snippet.

Reply 3594 of 3949, by VicRattlehead

User metadata
Rank Newbie
Rank
Newbie

Experienced an issue with Darkened Skye that may or may not be dgVoodoo2 related:

I experienced artifacts (flickering objects, broken graphics spontaneously popping across the screen) when setting the game to use "dgVoodoo TnL HAL" in the game's Config.exe AND when running the game in Windows 7 or XP SP2 compatibility mode (haven't tried other modes). Using "dgVoodoo HAL" seems to have no problems so far.

As a side note, the reason why I ended up having to run the game in Windows 7 compatibility mode is because at least one part of the game freezes when not using it. Additionally, I had to use BES with the game to keep the game from randomly instantly skipping cutscenes.

Reply 3595 of 3949, by UCyborg

User metadata
Rank Member
Rank
Member
Dege wrote:

Thanks for the extra level to try!
I've just tested it through developer mode with bump mapping/trilinear filtering/lens flare etc. enabled but I didn't get FPS dropdowns.
Aside from some temporal and minor fallback I got constant 60 fps in 4K without MSAA enabled, didn't matter if I breathed fire or saw the lens flares.

That's strange. Is there something radically different about our systems that you don't experience it? My GeForce GTX 750 Ti is indeed from 2014, so not exactly bleeding edge. I did update drivers recently to something newer (391.35 on the main Windows 8.1 installation, though I do have 397.64 on my the test Windows 10 installation), which doesn't help. Another guy on Arokh's Lair forum mentioned the same problem and he has Radeon R7 260x. The other card I have is Radeon R2 in a laptop (part of AMD E1-6010 APU). If I get a chance, I might be able to test it on another laptop with Intel HD 4000 to see if it's any different there.

I do have all eye candy in-game enabled, plus 16x anisotropic filtering and 8x MSAA forced through dgVoodoo. I did test both with default settings in dgVoodoo and with the old binaries from 2000 as well as patched ones from my patch, which you may want to download, it's got a bunch of quality of life improvements over the original.

The results didn't differ between game versions, though they are better if you use low resolution in-game and let dgVoodoo force a higher one. It's still laggy though, just that FPS doesn't drop to 10-15, but rather 35-40. Small UI doesn't bother me, so I just go with 1920x1080 resolution in-game with Unforced setting in dgVoodoo, VSync left enabled in-game and FPS capped to 59 for better mouse response with VSync.

This issue is separate from the one that results in low-frame if you enable debug messages in developer tab and which can be sped up with fast video memory access option, which doesn't help in this case. Drakan does have console/text chat prompt, but it isn't problematic, just the debug messages are.

Either way, I'm stumped...

Dege wrote:

Best would be to patch Drakan to be compatible with fast vidmem access.

Agreed.

Dege wrote:

Once I debugged out that Drakan reads cursor bitmap through ReadFile directly to the mapped area of its texture.

Since you mention ReadFile, it uses that call regularly during gameplay. Was that how you saved memory in the nineties, by constantly reading certain data from disk instead of loading it into RAM? Drakan works on systems with 16 MB of RAM. And the worst graphics card it can run on is S3 Virge from 1995! It's anything but smooth with such configuration, even with Voodoo 1, it fares poorly according to this.

There are also 2 versions of one function in the engine, the regular one that does the math with FPU and the other that uses AMD 3DNow!. No performance difference on my older CPU, which still has support for that instruction set. I haven't found any documentation whether there was any difference on the CPUs of the time.

It also uses GlobalLock/GlobalUnlock/GlobalAlloc/GlobalFree for memory management, a relic from 16-bit Windows. Another optimization attempt? It's strange since the engine was new, written from scratch, designed to utilize bleeding edge tech of the time.

Dege wrote:

I think it's matter of the code rewritten by inserting a temporary area with a memory copy. I'll try to dig out that code snippet.

Cool! 😎

BTW, I noticed dgVoodoo now works with Drakan's Level Editor application without crashing, though it's about as glitchy as it is on Linux with WINE (if I remember correctly, it's better if you set DirectDrawRenderer to gdi in registry). I'm guessing that mix of GDI and DirectDraw is pure mess. It also causes composition to go off on Windows 7/Vista (at least natively).

Arthur Schopenhauer wrote:

A man can be himself only so long as he is alone; and if he does not love solitude, he will not love freedom; for it is only when he is alone that he is really free.

Reply 3596 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

Thanks, now I installed your Drakan patch and tried the game at 2560x1440 app resolution. Indeed, this time I got constant 40 fps on my GTX1060.
One thing that didn't come to my mind at all explains the fps drops for lens flares: Drakan relies on the good old technique, namely locking the depth buffer for CPU access and reading back depth values to determine if the sun is visible or not (to draw or not to draw lens flares) for each frame.
The larger application resolution the more expensive the readback is.

Fast vidmem access is basically intended for usage patterns like that, so first I patched the exe to be compatible with fast vidmem access.
There seems to be a general bitmap reader function inside Drakan that reads bitmaps (textures and such) and uploads them into DDraw surfaces.
For textures, it reads the data into a temporary area and uploads it from there. For the cursor bitmap (32x32 16 bit) however, interestingly, it reads the data by ReadFile directly into the mapped surface area.
It's a bad practice because the stride for the surface should be taken into account (width*byteperpixel is not always equal to stride) but works after all, I even designed dgVoodoo to provide width==stride type mappings because there are plenty of games assuming it.
The base problem with the cursor bitmap reading is that dgVoodoo doesn't notice that surface content changes. I inserted a little code snippet into the reader function that 'pokes' the mapped surface area, by writing one byte into it before ReadFile gets called. Dirty, but works for the cursor.

Drakan became fastvidmem-compatible this way but sadly, it didn't help for lens flare. As for why, it's another interesting thing:
The game can only work with either pure 16 bit or pure 24 bit depth buffers. By default it chooses the largest bit depth, so 24 bit in our case. When saying 24 bit, I mean real 24 bit, 3 bytes per pixel.
But dgVoodoo cannot currently provide fast-access for 3 byte per pixel surfaces, so Drakan runs the same way as before. 🙁 It isn't a problem in general because 24 bit surfaces can only be software ones through dgVoodoo, except this type of depth buffer (which must be supported).

From curiosity I tried what happens if I restrict the max bit depth to 16 bit in the game callback for EnumZBufferFormats. Well, everything worked as expected. I got no fps drops, nice constant 60fps.
Then I tried the other way, what if I force the callback function to accept D24S8 depth format (all in all it's 32bit but the depth component is still 24). No more fps drop but lens flare disappeared in return, so I checked out the code reading back the depth values.
Indeed, it behaved badly, so I patched even this one. Lens flare were back but something went wrong with game draw distance...

That's the current state, so for now there are 2 workarounds:
- either limit Drakan to 16 bit depth buffers (doesn't sound good, I don't know what glitches it brings in)
- use low ingame-resolution and force it to high through dgVoodoo