Dege wrote:

This games uses OLE32 to create a DDraw object (CoCreateInstance) so it's incompatible with dgVoodoo... :( I don't know how to w […]
Show full quote

ZellSF wrote:

Outlive actually has a demo. It's not important (mediocre game that works perfectly natively anyway), but it's probably only a simple check you're missing:
http://www.fileplanet.com/56536/download/Outlive-Demo

This games uses OLE32 to create a DDraw object (CoCreateInstance) so it's incompatible with dgVoodoo... 🙁
I don't know how to workaround these cases, I don't want to create an installer which replaces system files, etc.
I think the simpliest way would be creating a small ole32 wrapper dll but I don't want to target this for the time being.

Maybe look at how DXGL does it? Unless some licensing issue prevents that.

Edit: Lands of Lore II presents an interesting problem. It's a 640x400 game. The DOS version software version defaults to this, 3dfx defaults to this, Windows software defaults to this... But Windows hardware version can't do this. It does 640x480 and letterboxes it, distorting aspect ratio. Back in the day I suppose you could just adjust your monitor...

DXGL does the same, so I'm assuming it's intended behavior (edit: yes it is), but it would be nice to have a workaround.

There is no reason to create a ole32 wrapper dll, etc.
CoCreateInstance just calls the ddraw.dll DllGetClassObject export.

IIRC, DllGetClassObject returns a IID_IClassFactory interface which is then used to create the DirectDraw Interface.
This is handled in my ddraw wrapper https://github.com/aqrit/ddwrapper/blob/maste … lassfactory.cpp
It is also handled by the DxWnd project, somehow.

Twisted Metal works, FVMs don't (works with DXWnd, fails with DXGL). Some menu rendering glitches.

Some menu glitches that are probably unrelated to dgVoodoo2 (times out and goes into attract mode too soon , better press start game within a second). CPU speed/timer related? If you try to use CPU grabber then it works but there's not enough CPU left for dgVoodoo2 to render smoothly. The game speed is also weird, probably a game that's better left to PSX emulators...

Twisted Metal 2 however had a pretty nice PC version. In dgVoodoo2 it lacks FMVs and input binding screen is broken, otherwise perfect. FMVs work natively.

Swat 3 Elite Edition perfect at 60 fps, without dgvoodo 3-12 fps
Monkey Island 4 perfect at 60 fps, without dgvoodo 12-25 fps
Die Hard Nakatomi Plaza perfect at 60 fps (texts are distorted), without dgvoodo 55 fps
Kingpin ok with dgvoodo (texture 8 bit slightly better but I am not sure about this)
Final Fantasy 8 (2000 version) in game 30 fps, in battle mode 15 fps but it's ok

Final Fantasy VII runs field maps at 30 FPS and battles at 15 FPS (intended behavior), so I'm guessing it's supposed to be that way for VIII too.

dege, Can you post beta version with extended resolutions API for testing purposes? Thank you in advance 😀

Dege wrote:

But with one monitor this can indeed be a problem, it all is not so bad idea. I will consider this, after all a there is room for a 'borderless, centered' option on the General tab.

I've meant that the window have to be borderless only when it doesn't fit screen with title and borders 😀 For example, if game's menu is 640×480 it will be in the window, but when gameplay is started and its resolution equal to system resolution, it will look like fullscreen 😀 IMHO it will be better. Do it as you see fit.

Also it is very interesting when are you planning to release the new version? Can I include glide3x.dll into default set of thrash drivers of NFS3 Widescreen Patch? I will write a notice about it in the readme.txt. The name of thrash video driver will be dgvoodoo.

If you know some bad things that NFS3 does (maybe you've debugged it for dgvoodoo), tell me, maybe it's better to fix it directly in the game binary.

Also there is one interesting thing. NFS3 doesn't have fog effect and light beams effect in DirectX 3D mode. I've enabled light beams effect for this mode, but it seems that default thrash driver doesn't support fog, so when I enable according code in the nfs3.exe for the D3D mode it produces some artefacts with horizon and no fog. But it seems that thrash API according to fog was changed when NFS4 was released. So when you try to use thrash driver voodoo2 from NFS4+ there will no fog effect. Only voodoo2 thrash drivers from games between NFS3 and NFS4 (FIFA99, Future Cop) supports this API for fog effects.
But it seems that early demo of NFS4 used thrash drivers with old fog API. In late 90's and early 2000's many users had got d3da.dll from NFS4's 3dsetup directory (there is a copy of this file from early demo), renamed it to voodoo2a.dll and placed it to NFS3 directory. As a result (as they say) fog effect worked without voodoo2 cards via DirectX 6. But on modern systems this driver crashes the game just after start. I've tried to run it with your DirectX wrapper with same result. Maybe it will be not so hard for you (with source codes of DX wrapper) to see what bad thing this thrash driver does and which have to be fixed to run properly? This file is here: http://nfs2004.ru/tntpatch.zip (it's already renamed to voodoo2a.dll). If it requires much time, don't waste time for it. If we could fix it, I'll add full-fledged support of fog for thrash drivers with d3d/dx* names.

Pro Pinball games mostly work fine. They sometimes minimize and you have to manually restore them when loading the table though.

Big Race USA has some performance issues if you max out both resolution and colors. Still runs at above 50 FPS, but sound runs into issues. Reducing the color setting or resolution setting by one step helps (and doesn't have a major impact on visual quality imo).

The Web only runs at 40 FPS. It seems locked to that, I'm not sure if it's dgVoodoo (game runs terrible natively) or really weird design decision. I think it's intentional though.

Fantastic Journey and Timeshock are perfect.

Puyo Puyo 2, Sun and Fever all perfect (not sure if a Windows version exists of 1).

Carmageddon has garbage in menus after first time you start a race (in DXGL too, but cnc-ddraw is perfect).

Valkyrie: The Magical Odyssey crashes with "Request failed". It works natively in compatibility mode (outside of it it does the same as dgVoodoo2).

POD's software render fails "lpDD::SetDisplayMode->DDERR_UNKNOWN", doesn't work with DXGL either (replace last part with INVALID_PARAMS), works natively. D3D version fails, possibly because it demands the desktop be set to 16-bit color? Doing so results in an instant silent crash.

Balls of Steel is perfect. It is however one of the game with severe vsync performance problems in dgVoodoo2.

VEG wrote:

dege, Can you post beta version with extended resolutions API for testing purposes? Thank you in advance 😀

I can share the current build but it hasn't changed much since 2.44.
I fixed a bug in DX (Grandia2) and did some other refactoring but that's all, and, implemented the resolution extension in Glide. (I also included the string "RESOLUTION" in the extension string query for the cases this extension is supported).

http://dege.fw.hu/temp/dgVoodooWIP7.zip

@everybody: Sorry for the short answers and low activity but lately I don't have much time. But I'm going to keep working on, of course. 😐

New Glide3x.dll is for napalm folder too?

New Glide3x.dll is for napalm folder too?

No, it's a plain Glide3 without Napalm for VEG, to test it with his patch.

BTW, this patch is very cool, you had to know NFS internals well VEG, to write it. Tons of debugging game assembly, right? 😀

Also it is very interesting when are you planning to release the new version? Can I include glide3x.dll into default set of thrash drivers of NFS3 Widescreen Patch? I will write a notice about it in the readme.txt. The name of thrash video driver will be dgvoodoo.

Unfortunately, I never know when the next version will be released. The general "rule" is "when right amount of fixes and developments piles for a release".
But it's not the case now, so if this WIP version works fine then you can include it in your patch, I think. Thanks for that! 😎
The version of the dll is still 2.44 and it's not the same as the latest released version but I don't think it's a problem.

Also there is one interesting thing. NFS3 doesn't have fog effect and light beams effect in DirectX 3D mode. I've enabled light beams effect for this mode, but it seems that default thrash driver doesn't support fog, so when I enable according code in the nfs3.exe for the D3D mode it produces some artefacts with horizon and no fog. But it seems that thrash API according to fog was changed when NFS4 was released. So when you try to use thrash driver voodoo2 from NFS4+ there will no fog effect. Only voodoo2 thrash drivers from games between NFS3 and NFS4 (FIFA99, Future Cop) supports this API for fog effects.
But it seems that early demo of NFS4 used thrash drivers with old fog API. In late 90's and early 2000's many users had got d3da.dll from NFS4's 3dsetup directory (there is a copy of this file from early demo), renamed it to voodoo2a.dll and placed it to NFS3 directory. As a result (as they say) fog effect worked without voodoo2 cards via DirectX 6. But on modern systems this driver crashes the game just after start. I've tried to run it with your DirectX wrapper with same result. Maybe it will be not so hard for you (with source codes of DX wrapper) to see what bad thing this thrash driver does and which have to be fixed to run properly? This file is here: http://nfs2004.ru/tntpatch.zip (it's already renamed to voodoo2a.dll). If it requires much time, don't waste time for it. If we could fix it, I'll add full-fledged support of fog for thrash drivers with d3d/dx* names.

Hmm, ok, I'm going to try this, I'm curious.

Dege wrote:

Tons of debugging game assembly, right?

Yep 😀

Dege wrote:

Hmm, ok, I'm going to try this, I'm curious.

I've tried to use this dx6 thrash driver (as voodoo2) on Windows XP x32, and there is fog effect! Wow, it works! It will be very nice to fix this dx6 driver for modern operating systems.

I did a quick try with that driver and indeed it crashed.
It's because it overwrites its own internals if more than 11 texture formats are enumerated to it.
I did a very quick patching to allow only the first 11 texture formats. Now it works but I still get no fog with it, neither with dgVoodoo nor natively.

Dege wrote:

I did a quick try with that driver and indeed it crashed.
It's because it overwrites its own internals if more than 11 texture formats are enumerated to it.
I did a very quick patching to allow only the first 11 texture formats. Now it works but I still get no fog with it, neither with dgVoodoo nor natively.

Oh, thank you. This thrash driver definitely works with fog on my Windows XP with old Nvidia drivers. I think that there is some check which detects if fog is supported by GPU and this check is failed on modern OS. For example, in nfs3.exe was GPU memory check. Memory size was stored in signed int32, so when user have more than 2Gb of RAM, game thinked that there is not enough memory... I've fixed this. Maybe something like this also causes problem with fog there.

VirtuaIceMan wrote:

One more: Johnny Herbert's Grand Prix Championship 1998... […]
Show full quote

One more: Johnny Herbert's Grand Prix Championship 1998...

The games that use tweaked versions of the Johnny Herbert 3D engine, namely Grand Prix Championship 2 and GP vs Superbike, both work fine with dgVoodoo, but JHGPC98 needs IgnoreException applying to even load (or Win98 mode, which includes this), then the game crashes loading a race.

In the past I managed to create a hybrid version, by copying parts of GPC2 over the JH folder, but then you get the same graphics issues that GPC2 and GPvsSB both have: namely a lack of chrome reflections on the car, and thick black skid marks when driving on grass (compared to semi-transparent).

HOWEVER, I only ever managed to get the original JH game to work on my ancient Win98 machine running a Voodoo5 graphics card, so there could be more to this than meets the eye, as I never got it working on WinXP without the hybrid GPC2 files overwrite approach.

You can see the difference in these snapshots I took years ago:

Johnny Herbert's Grand Prix Championship 1998 (chrome on cars and transparent skid marks on grass (not shown)):
[/URL]

Grand Prix Championship 2 (no chrome and black skid marks on grass (not shown)):
[/URL]

There's a demo of JHGPC here (needs Win98 mode applied to do anything), but it crashes natively and shows a black screen with dgVoodoo logo then crashes with dgVoodoo: https://archive.org/details/JohnnyHerbertsGra … ldChampionsDemo

p.s. Johnny Herbert runs a similar engine to Castrol Honda Superbike World Champions (and the 2000 sequel), which I haven't played around with too much, as that's flakey too. Fascinating fact: the engine actually was a Direct3D version of the one in Power F1 DOS game, so it goes waaaaay back...

aqrit wrote:

There is no reason to create a ole32 wrapper dll, etc. CoCreateInstance just calls the ddraw.dll DllGetClassObject export. […]
Show full quote

There is no reason to create a ole32 wrapper dll, etc.
CoCreateInstance just calls the ddraw.dll DllGetClassObject export.

IIRC, DllGetClassObject returns a IID_IClassFactory interface which is then used to create the DirectDraw Interface.
This is handled in my ddraw wrapper https://github.com/aqrit/ddwrapper/blob/maste … lassfactory.cpp
It is also handled by the DxWnd project, somehow.

Thanks!
Maybe I misunderstood this all because I thought CoCreateInstance searches for a given guid in the registry, where (GUID, dll with full path) pairs are stored (that can be registered by regsrv32), and, since the dll is stored with full path, it always finds the native ddraw.dll in system32 folder.
But I don't know if CoCreateInstance also applies a sequence of search paths like LoadLibrary, I will check it out.

EDIT: Just checked it and it indeed works!! Yuhuuu!

Oh, thank you. This thrash driver definitely works with fog on my Windows XP with old Nvidia drivers. I think that there is some check which detects if fog is supported by GPU and this check is failed on modern OS. For example, in nfs3.exe was GPU memory check. Memory size was stored in signed int32, so when user have more than 2Gb of RAM, game thinked that there is not enough memory... I've fixed this. Maybe something like this also causes problem with fog there.

When I debugged a little it showed that the driver first enables exponential pixel fog with a factor of 0.004 or sg like that, draws sg, then disables it, and so on, but I didn't debugged it at polygon level. So it seems that it should work but i doesn't do that for some reason. (Or, old drivers misinterpreted pixel fog parameters?)

There's a demo of JHGPC here (needs Win98 mode applied to do anything), but it crashes natively and shows a black screen with dgVoodoo logo then crashes with dgVoodoo: https://archive.org/details/JohnnyHerbe ... mpionsDemo

BTW, I tried F1 Championship Season 2000 Demo, it works with latest WIP, the game can run in hw mode but it's quite ugly, pixelated and certain polygons are missing (from car wheels, for example).
Also tried JHGP and it crashes. This game tries to use execute buffers in very obscure way, no wonder why it crashes (bad creation paramters, heavy buffer overwriting).
My only tip is that memory overaddressing on Win98 caused no problem in practice and it worked after all.
I don't see much chances for this, maybe a torturer patching could help. 😀

Ah cool, I'll have a look at F1CS2K later. Johnny I might have to just use my "overwrite bits with parts from GP Championship 2" fix.

BuckoA51 wrote:

Also I'll update my article on BOF4 as I could only run that in XP before.

I just tested and it also runs in WineD3D (on a 570/Win7, less luck on a 670/Win8... weird). Poor framerate, but no text issues. Which could point to that not being a Nvidia bug, but a dgVoodoo2 bug.

Looks like Dege's not the first to have problems with Breath of Fire IV text rendering though.

Dege wrote:

BTW, I tried F1 Championship Season 2000 Demo, it works with latest WIP, the game can run in hw mode but it's quite ugly, pixelated and certain polygons are missing (from car wheels, for example).

For me, it looks fine, but crashes when loading a race (the 3D car looks great though). To get best quality, once you've run F1Config.exe, edit CONFIG.INI and set SystemRating=5, otherwise the graphics will be compromised.

I only ever managed to get into a race once in hardware mode though, not sure what's crashing it... this is the F1CS2K demo FYI.

Actually, trying the original F1 2000 and F1CS2K full game, both seem to crash if the graphics are turned up too much in the in-game graphics menu...

Hmm, update, seems more weird than that. By step-by-step increasing the quality of graphics in the demo (when running with SystemRating=5), I managed to switch on everything, and the hardware version still worked. I thought it was because I waited a few seconds on the car and track select screens before pressing the button... but after trying the same in F1 2000 full game it didn't work, and now, nor does F1CS2K demo, crashing whilst loading the race!

The crashes I get with the demo are:

1Faulting application name: F1CS2000_Demo.exe, version: 0.5.8.0, time stamp: 0x3a1971f9
2Faulting module name: F1CS2000_Demo.exe, version: 0.5.8.0, time stamp: 0x3a1971f9
3Exception code: 0xc0000005
4Fault offset: 0x0011d62b
5Faulting process ID: 0x2ad0
6Faulting application start time: 0x01d09d8df0236202
7Faulting application path: D:\f1cs2k\F1CS2000_Demo.exe
8Faulting module path: D:\f1cs2k\F1CS2000_Demo.exe
9Report ID: 41f6132e-0981-11e5-8389-7824af8a9e0a
10Faulting package full name: 
11Faulting package-relative application ID: