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.