I've got a problem with 2.51 with Blood 2.

My windows mouse pointer is flickering into the game for some ms frequently.

It didnt happen with v2.50.

Maybe it has something to do with the new "capture mouse" option? It doesnt make a difference if checkmarked or not. The problem is only solvable by using 2.5

Here my settings:

http://abload.de/img/dgvoodoo2_5___1mfb55.png
http://abload.de/img/dgvoodoo2_5___2trz8b.png

Hello, after a loong time lurking in this forums I registered basically to say "thank you" to dege for this awesome piece of software.

De-M-oN wrote:

I've got a problem with 2.51 with Blood 2. […]
Show full quote

I've got a problem with 2.51 with Blood 2.

My windows mouse pointer is flickering into the game for some ms frequently.

It didnt happen with v2.50.

Maybe it has something to do with the new "capture mouse" option? It doesnt make a difference if checkmarked or not. The problem is only solvable by using 2.5

Here my settings:

http://abload.de/img/dgvoodoo2_5___1mfb55.png
http://abload.de/img/dgvoodoo2_5___2trz8b.png

Try disabling antialiasing (MSAA).

Try disabling antialiasing (MSAA).

No option for me. The game needs AA badly.

I'm also very sure that the MSAA code of dgvoodoo wasnt changed compared to 2.50. In 2.50 it works fine.
_____________
On the other hand on 2.50 Need For Speed 2 refused to run in forced 2560x1600 or any other resolution. It stayed at 640x480. With this new 2.51 version it runs now with 2560x1600 😀

And I'm really really impressed what this piece of software does get out of the old games.

This is original 640x480, zoom in to see the heavy aliasing especially on the bridge:

http://abload.de/img/nfs2sea_2016_03_17_23lys76.png

Now see what dgvoodoo has done to this:

http://abload.de/img/nfs2sea_2016_03_17_23ecsej.png

I'm really impressed. just wow. The aliasing fully gone, while still being sharp. Impressive.

Stiletto wrote:

Their plans for the future at the time... Voodoo Rush is actually a very early card. Bet that's gone in a Voodoo3-era reference? 😉

I don't understand how Voodoo Rush came into the picture. (but maybe: Voodoo Graphics and Rush were just additional 3D accelerators attached to the 2D SVGA, which implies that achieving windowed mode on those cards are physically impossible.)

The Glide source I checked is from 2003 and the piece of code in question doesn't distinguish between card types for 'hwnd and windowed mode'. There is only an #ifdef linux AFAIR.

I bet in the docs they meant GR_RESOLUTION_NONE can be given into the init function and one can get into different situations as a result: if the underlying hw supports windowed mode then one gets a window, if not, then he finds himself in fullscreen. 😁
But, windowed mode was never implemented.

De-M-oN wrote:

I've got a problem with 2.51 with Blood 2. […]
Show full quote

I've got a problem with 2.51 with Blood 2.

My windows mouse pointer is flickering into the game for some ms frequently.

It didnt happen with v2.50.

Maybe it has something to do with the new "capture mouse" option? It doesnt make a difference if checkmarked or not. The problem is only solvable by using 2.5

Here my settings:

http://abload.de/img/dgvoodoo2_5___1mfb55.png
http://abload.de/img/dgvoodoo2_5___2trz8b.png

If scaling method of dgVoodoo set to any other than 'Stretch with AR' and the new 'Capture mouse' option is disabled then it works in the same way as 2.50. I tried 2.51 with Blood2 with every scaling method and didn't get flashing cursor (I'm running Win7 too).
It's true that 2.51 contains a new code path that can cause this phenomenon but shouldn't run onto that with 'unspecified' scaling mode.
So I don't understand why it is but will check again to make sure.
(MSAA has nothing to do with this.)

shiva2004 wrote:

Hello, after a loong time lurking in this forums I registered basically to say "thank you" to dege for this awesome piece of software.

De-M-oN wrote:

And I'm really really impressed what this piece of software does get out of the old games. […]
Show full quote

And I'm really really impressed what this piece of software does get out of the old games.

This is original 640x480, zoom in to see the heavy aliasing especially on the bridge:

http://abload.de/img/nfs2sea_2016_03_17_23lys76.png

Now see what dgvoodoo has done to this:

http://abload.de/img/nfs2sea_2016_03_17_23ecsej.png

I'm really impressed. just wow. The aliasing fully gone, while still being sharp. Impressive.

Thank you guys, it's always nice to hear that. 😀

Regarding Splinter Cell i see that some areas are displaying OK. You did something right. The behaviour i'm seeing now resembles of Geforce 7xxx cards. Some shadows show others do not.
Or it's just me and all of this already was happening.

Dege wrote:

Because DDraw could freely draw/overwrite arbitrary parts of the desktop (similarly to GetDC (NULL)) which is not compatible with desktop composition. Roughly, at the moment Windows detects that the application executes such an operation it shuts down DWM

Thank you for the explanation.

Dege wrote:

you can insert a manifest into your application promising that you're going to be a good boy

Do you know which setting does this? 😀

Dege wrote:

The game probably doesn't allocate a DDraw clipper for the output window (needless for fullscreen mode) which allows overwriting the content of other windows covering that one, independently on the window z-order.

Thanks for a hint. I've found information about it in the DirectX 7 documentation. I think I can do it 😀

Dege wrote:

Well, that's what the real Glide driver does: if the 'resolution' parameter is invalid (including GR_RESOLUTION_NONE) then it simply replaces it to 640x480.

It seems that you're right at least according to 3dfx Voodoo 4/5 and latest glide3x version. I had found a person with a working 3dfx Voodoo 5 and he had tested my code. Is it possible that they had removed this feature from the latest version of the Glide3x? I'm going to find someone with a 3dfx Voodoo Rush, which is mentioned in the Glide 3x SDK documentation.

Dege wrote:

As for the NFS3 fog, I didn't guess it's so complicated. 😀
Some day I check what's going on there. As I plan to do it for the DX8 thrash driver. Now I'm not sure that it doesn't use e.g. vertex buffers.
Messed up polygons must be the result of some invalid parameters pushed to one of the Draw calls.

Can you reproduce this problem (with DX8) on your PC? Usually the problem is not so dramatic. It can be just a small glitch on some places of a track. Probably, dx8a.dll does something wrong by itself, but without wrapper it works well.

Can you reproduce the problem with minimizing of the dgdx6? Probably, dx6a.dll does something wrong. Original dx6 can be restored after minimizing, but it loses all textures.

VEG wrote:

Do you know which setting does this?

I googled on what I remembered and I think that was the Win7/8 compatibility manifest:

https://msdn.microsoft.com/en-us/librar ... s.85).aspx

But, reading it carefully, it proves to be worse than I thought of. Win7/8 compatible apps cannot even lock the primary buffer and blit to a window without a clipper thorugh DDraw.
They get an error instead for those operations, so putting such a manifest into NFS3 would make that not work.

VEG wrote:

It seems that you're right at least according to 3dfx Voodoo 4/5 and latest glide3x version. I had found a person with a working 3dfx Voodoo 5 and he had tested my code. Is it possible that they had removed this feature from the latest version of the Glide3x? I'm going to find someone with a 3dfx Voodoo Rush, which is mentioned in the Glide 3x SDK documentation.

I doubt that. Windowed mode is different compared to fullscreen because buffer swapping must be performed by a clipped blitting to the window (early days), exactly like in DDraw (with possible color format conversion).
There is no any code in Glide sources doing such (an) operation(s), buffer swap is a simple command to the hw.
Not to mention that term of the 'front buffer' (and content of backbuffers) becomes untenable in windowed mode while Glide proves free access to it. So, windowed mode cannot be managed by just one 'bool' parameter at initialization. Either the driving part (application) must manage windowed mode differently, or the driver part must pee blood to emulate it transparently to the application but I didn't find any type of code in Glide sources, as for the latter. 😀

VEG wrote:

Can you reproduce this problem (with DX8) on your PC? Usually the problem is not so dramatic. It can be just a small glitch on some places of a track. Probably, dx8a.dll does something wrong by itself, but without wrapper it works well.

Can you reproduce the problem with minimizing of the dgdx6? Probably, dx6a.dll does something wrong. Original dx6 can be restored after minimizing, but it loses all textures.

Still didn't do extensive tests in this topic but I could repro the flashing polys on my nVidia.

daniel_u wrote:

Regarding Splinter Cell i see that some areas are displaying OK. You did something right. The behaviour i'm seeing now resembles of Geforce 7xxx cards. Some shadows show others do not.
Or it's just me and all of this already was happening.

Hm, I didn't tested SC with 2.51 and shadow buffers. But some of the fixings may have a side effect then. 😀
I will check it again some day, but I'm afraid it all worked well on GF4's because of a driver bug(s). If that is the case, it will be hard if not impossible to 'emulate' it.

Hi! I have a small problem with DDraw wrapper on Star Wars: Galactic Battlegrounds. When typing in certain text boxes, the letters aren't showing up (i.e. new profile names, save files). Here are screenshots with your wrapper and without it:
https://pp.vk.me/c628320/v628320806/4709a/wLDoRIbFahU.jpg
https://pp.vk.me/c628320/v628320806/47091/_MSeTXH46t0.jpg

Dege wrote:

daniel_u wrote:

Regarding Splinter Cell i see that some areas are displaying OK. You did something right. The behaviour i'm seeing now resembles of Geforce 7xxx cards. Some shadows show others do not.
Or it's just me and all of this already was happening.

Hm, I didn't tested SC with 2.51 and shadow buffers. But some of the fixings may have a side effect then. 😀
I will check it again some day, but I'm afraid it all worked well on GF4's because of a driver bug(s). If that is the case, it will be hard if not impossible to 'emulate' it.

Well i still have hope for this game. 😀
It would not be a surprise if Nvidia drivers would be at fault here.
Imho, the only way to be sure is to investigate using a Geforce 4. Maybe some forum members can help with some debuging logs or something. Too bad mine broke.
I have seen broken games due to drivers but this one is too broken. Must be something else. It's just a feeling , no proof. 😀

Another question:

You said in readme you could fix the z-fighting light problem on nightraces for NFS 3/NFS 4 by using a 16 bit Depth Buffer. Now I'm confused. Because: Do you remember the Texel Alignment Setting on old graphic cards? Default is 3. But NFS 3, NFS 4 and NFS Porsche need it to be set at 0.

If it is at 0 there is no z-fighting lights and the font in menus and so on is not that ugly, its then sharp. For NFS Porsche with Texel being at 3, even the windows dont shatter anymore if a car is upside down.

I see that the NFS 2 Font (look my screenshots at the recordtime for example) have the same weird look as if it would run at the wrong texel alignment. I remember it being sharp. At least for the software renderer.

So now my confusion is: What is texel alignment vs this 16-bit depth buffer? But maybe Voodoo cards even dont have texel setting? For Nvidia at least it was important

A Texel alignment setting within dgvoodoo would be otherwise imo a nice feature.

VEG: A little off-topic: Windowed-mode Glide was VERY uncommon if not impossible back in the Voodoo2/Rush/Banshee days. It inspired the creation of a "wrapper" (so to speak) called WinGlide, look it up: http://www.falconfly.de/tools.htm - it's more like D3DWindower and DxWnd but circa 1998-2000. Even so, it was taking the output of Glide and chucking it into a DirectX Overlay, or other things (there were a few versions)
(yes, we have Justin Frankel of WinAmp fame to thank for it)
Falconfly has a few old versions, I have a good chunk of the rest in The Wrapper Project archive.

Dege wrote:

vis wrote:

Greetins to all! Ty for your work, dege and tnx to all people who helped you! : ) I am posting on vogons first time and wish to […]
Show full quote

Greetins to all!
Ty for your work, dege and tnx to all people who helped you! : )
I am posting on vogons first time and wish to directly, here, report one problem that I discovered during testing dgvoodoo 2.45 ver(older ver did give same result) with Turok 2 Seeds of Evil game. It is about mouse bug that is present in single player and multi player, when direct x emulation is in use, try dgvoodoo direct x wrapper. Please look video here, dege, cos my eng. is not good enuf: https://youtu.be/BQ_LavLt03g
Now to say, normal dx 6.1 works without any problem and I already playing T2 MP more then 3 year, so if there was same/similar problem, caused with anything else, I would know. I did test old-new versions of dx wrapper in Diablo 2 LoD and worked perfect, incomparable better then native dx in that game, if we look by fps and stuttering, there was not any mouse bug. I did find 3 bigger bugs, before. One, messed colors when is older then 3xx.xx nvidia driver used (460 gtx) second, in some older ver of wrapper, steam overlay would stay bugged, if game with opened steam overlay menu, was minimized and 3th: games would crash often during minimizing/maximizing process. All 3 bug are now gone, tnx to driver update and fix's that are in latest dgvoodoo warper. What is more positive about dx 1- 7 emulation: when it's used in games, steam overlay working vs original dx mode , when it can't, then Nvidia DSR becomes available and final, most important: it is potential, best solution for any quality, retro gaming on Microsoft OS, newer then win 7 (which I use : ) cause notorious broken support for older dx versions, started from win 8 to latest Yes I talking about locked fps and fps drops... So wish you, all luck on finishing of this great project, dege. Ty and please, help us, considering that small player base which is still active in T2 MP, would benefit from using this software, after successful resolving of this annoying bug. 😀

Hi!
Thanks for the report. It's cool dgVoodoo2 works fine for you in general. 😀
I can't test Turok2 at the moment but I'll have a look. Back when I tested it with Glide rendering, it worked without a problem (but can't remember if I tried the game with DX wrapping).

Well, dege i have new things to report : O hehehe : on ver 2.5 and 2.51 , game Turok 2 SoE works fine in window mode, nice fps boost vs orginal dx mode, even with dxtory it shows progress (can record with rbg color space vs native dx mode where i had fps drops if i lift up quality ) Plus, included D3DCompiler_43 alowing me to use older nvidia drivers ( one with maximum pre-rendered frames 0) without reported color bug : ) Now about negative aspect with 2.5x ver: i know why mouse was moving automatic! If i, in dgvoodoo configurator, uncheck option 'Disable Alt-Enter to toggle screen state' then mouse problem is solved, in Turok 2. I tested it in 2.45 ver to, and geting same result. Now when i select 'Aplication controlled fullscreen/window state' with it, it all works perfect in 2.45 ver, in fullscreen to. In 2.5 ver , same combo, makes weard bugs, when i minimasing, maximasing, game window stuck, random crashing to. In 2.51 ver, i couldn't do fullscreen test, because is broken for T2 : I. It just loads with black screen. Well, here link for T2 demo: https://archive.org/details/turok2demo
So you can test with it to, ty. One observacion more: i not sure if you know, but T2 needs one core affinity to be stable, because T2 have many critical bugs on modern multicore cpu (we play it with fix from here: http://ctpax-cheater.losthost.org/htmldocs/turok.htm search for : Turok 2: Seeds of Evil CD Music Patch v2 ) so, maybe, your dll's not like case when game use only one cpu core. I hope, this info will be of help for future testing. Hu : )

The GTA3 opening videos are black, they work fine native.

I see the the ref count scheme was changed in the latest version...

now my texture swap patches work in many games without modification from the code that works on Microsoft's ddraw.

😀 😀

Sadly Resident Evil 2 stopped working

Thanks for the reports, guys!

vis wrote:

Well, dege i have new things to report : O hehehe : on ver 2.5 and 2.51 , game Turok 2 SoE works fine in window mode, nice fps boost vs orginal dx mode, even with dxtory it shows progress (can record with rbg color space vs native dx mode where i had fps drops if i lift up quality ) Plus, included D3DCompiler_43 alowing me to use older nvidia drivers ( one with maximum pre-rendered frames 0) without reported color bug : ) Now about negative aspect with 2.5x ver: i know why mouse was moving automatic! If i, in dgvoodoo configurator, uncheck option 'Disable Alt-Enter to toggle screen state' then mouse problem is solved, in Turok 2. I tested it in 2.45 ver to, and geting same result. Now when i select 'Aplication controlled fullscreen/window state' with it, it all works perfect in 2.45 ver, in fullscreen to. In 2.5 ver , same combo, makes weard bugs, when i minimasing, maximasing, game window stuck, random crashing to. In 2.51 ver, i couldn't do fullscreen test, because is broken for T2 : I. It just loads with black screen. Well, here link for T2 demo: https://archive.org/details/turok2demo
So you can test with it to, ty. One observacion more: i not sure if you know, but T2 needs one core affinity to be stable, because T2 have many critical bugs on modern multicore cpu (we play it with fix from here: http://ctpax-cheater.losthost.org/htmldocs/turok.htm search for : Turok 2: Seeds of Evil CD Music Patch v2 ) so, maybe, your dll's not like case when game use only one cpu core. I hope, this info will be of help for future testing. Hu : )

But, I've just tested both Turok 2 Demo and full game with 2.51 and it seems to work very fine. No black screens, tried with various options you mentioned.
Till 2.5 there was a bug present which indeed caused auto-moving cursor in Turok2 but I fixed it in 2.51 (it also caused minor anomalies in Croc and South Park).

XAP4O wrote:

Hi! I have a small problem with DDraw wrapper on Star Wars: Galactic Battlegrounds. When typing in certain text boxes, the letters aren't showing up (i.e. new profile names, save files). Here are screenshots with your wrapper and without it:
https://pp.vk.me/c628320/v628320806/4709a/wLDoRIbFahU.jpg
https://pp.vk.me/c628320/v628320806/47091/_MSeTXH46t0.jpg

Peixoto wrote:

Sadly Resident Evil 2 stopped working

Must check it myself...
Seems to be bugs.

Peixoto wrote:

I see the the ref count scheme was changed in the latest version...

now my texture swap patches work in many games without modification from the code that works on Microsoft's ddraw.

Great! 😎
But I didn't changed DDraw/D3D refcount scheme. 😀 As far as I remember. Isn't it a side effect of something else?
The only thing I changed, related to the ddraw refcount, was that 2.51 doesn't allow releasing implicitly created surfaces in a complex chain (like backbuffers in a fullscreen buffer chain),
because only the head element can be released if the app drives ddraw properly (not by the lame 'solution' I encountered so many times, namely, calling ->Release in a while cycle until it returns 0... 😵 ).
Instead, it returns refcount 0 but internally doesn't release those surfaces, only when the head is released.
(Omikron - Nomad Soul applies the lame solution which MS ddraw survived but dgVoodoo didn't).

MrEWhite wrote:

The GTA3 opening videos are black, they work fine native.

Yes, it's a known thing.
D3D8 games using DirectShow (quartz.dll) for their movie playback only shows black screen through dgVoodoo (in fullscreen).
A half-baked solution is ready, e.g. GTA3, BloodRayne2, and Blade of Darkness now all show their movies (didn't do extensive tests so far on this), but it still needs some additional API hooking. And, since quartz plays back movies through DDraw, DDraw will be needed for even such D3D8 games (can't work with native DDraw - dgVoodoo DX8 combo).

De-M-oN wrote:

Another question: […]
Show full quote

Another question:

You said in readme you could fix the z-fighting light problem on nightraces for NFS 3/NFS 4 by using a 16 bit Depth Buffer. Now I'm confused. Because: Do you remember the Texel Alignment Setting on old graphic cards? Default is 3. But NFS 3, NFS 4 and NFS Porsche need it to be set at 0.

If it is at 0 there is no z-fighting lights and the font in menus and so on is not that ugly, its then sharp. For NFS Porsche with Texel being at 3, even the windows dont shatter anymore if a car is upside down.

I see that the NFS 2 Font (look my screenshots at the recordtime for example) have the same weird look as if it would run at the wrong texel alignment. I remember it being sharp. At least for the software renderer.

So now my confusion is: What is texel alignment vs this 16-bit depth buffer? But maybe Voodoo cards even dont have texel setting? For Nvidia at least it was important

Well, I don't really know...
Texel alignment on old GPU control panels was for adjusting pixel center/texel center manually for games that were written for bad drivers that weren't compliant to the D3D standard.

I guess If texel/pixel center is misaligned then z-fighting can occur because projected headlights are mis-rendered by 1 pixel or sg like that and the outgoing z-values don't match the ones in z-buffer. Perhaps.

De-M-oN wrote:

A Texel alignment setting within dgvoodoo would be otherwise imo a nice feature.

We were talking about that previously but I don't want such a setting. It would just confuse the average user.

Any progress with the X-Wing Alliance issue?

Dege wrote:

My tip is the missing DDraw hwnd clipper (not too complicated to create and attach one if you have a DDraw object instance).

DX6 and DX7 renderers have the code that adds hwnd clipper (I had found it and it works). I've added

1	<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application>
2		<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" /><!-- Windows Vista -->
3		<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /><!-- Windows 7 -->
4	</application></compatibility>

to the manifest and as the result DX7 works ok (there is no video because nfs3 can't render it in 32bpp) and system doesn't switch to the basic theme. DX6 had shown an error (because of improper error handling in the thrash_lockwindow function when surface locking is failed), but I have it fixed and it also works nice. So, thank you for your hint =)

Can you reproduce the problem that NFS3 with the DX6 renderer + dgVoodoo wrapper can't be minimized properly?

We were talking about that previously but I don't want such a setting. It would just confuse the average user.

Then they should read how to use their software.

Seriously - settable Texel would finally fix NFS 3, NFS 4, NFS Porsche for having ugly font and that headlight problem. It must be zero for these NFS. Especially NFS Porsche suffers from Texel 3. Really ugly font, windows dont shatter anymore etc.
And the headlight problem is a real issue too for drivers like me who prefer to drive at bumper camera.

I agree with dege, that option is too confusing.