Hey Dege. I really love your new version of dgVoodoo. I used the old versions too to play carmageddon 2.
Could you possibly add the ability to set the desired refresh rate in this new dgVoodoo?
I have a monitor that blurs the image when using 60hz for my native res and prefers 75hz and carmageddon 2 keeps starting in 60hz and I can't do anything about it.
It would be really helpful if your new dgvoodoo would allow you to force the desired refresh rate into the game.

Mr.Deviance wrote:

Hey Dege. I really love your new version of dgVoodoo. I used the old versions too to play carmageddon 2.

Thanks! 😀

Could you possibly add the ability to set the desired refresh rate in this new dgVoodoo?

I was asked for the same by CaidKein because it seems his HDTV couldn't handle 1900x1200 at 60Hz but only in interlaced mode (so that only 30Hz, if I think it right).
I avoided overriding refresh rate on purpose because it caused a lot of problems and misunderstandings in the old versions.
If another refresh rate is used than the application is assuming then it can cause out of sync effects like lagging animation, sound and graphics out of sync, etc.
In the best case it wouldn't cause any glitch but only the game speed would change slightly if the games does nothing but synchronize itself to the vertical retrace (for example, a game assuming 60Hz when 120Hz is used instead would cause the game to run at double speed in such a case).

So, it could be exposed in the setup but only exactly in the same way as resolution and antialiasing: if other than the default causes glitches or laggings for a given game then one can do nothing but accept it.

I understand. Well I would really like to have that setting if you add it, it would be great.
Also, the 3dfx Splash screen and 3dfx watermark don't work for me.
Not that I need them, I just wanted to point this out.

Mr.Deviance wrote:

I understand. Well I would really like to have that settings if you add it, it would be great.

Ok, I'll consider this.

Also, the 3dfx Splash screen and 3dfx watermark don't work for me.
Not that I need them, I just wanted to point this out.

Did you download the 3Dfx splash dlls? dgVoodoo needs them but didn't wanted to include them in the dgVoodoo pack to keep its size small.
I myself put them into the Windows\SysWOW64 directory:

http://dllfiles.co/3dfxspl2-dll/
http://dllfiles.co/3dfxspl3-dll/

Aww thanks I didn't know about them. Now it works.

Dege wrote:

I couldn't run Turok2 for the sake of God when I wanted to fix that.
But now I've just downloaded its demo and it's running fine with all the problems you talked about.
I'm going to fix it and release a patch patching version. 😀

That's great to hear!

swaaye wrote:

That's great to hear!

I've fixed it. 😎
Very nice game.

However I run into a multithreading problem while debugging. AFAIK the original drivers weren't (multi)threadsafe but I want to look into that deeper and make the Glide renderer partly threadsafe if needed.
Also, this is a game using z-buffering which means it's better to use '16 bit depth buffer' to avoid some z-fighting appearing with shadows. I'm considering removing that option and let the wrapper choose. But I'm not sure if it's a good idea. Maybe in a later version.

Just released the new version.
Shortly: Turok2 is fixed and possibility of refresh rate overriding is added.

Dege wrote:

Just released the new version.
Shortly: Turok2 is fixed and possibility of refresh rate overriding is added.

I'll give it a go when I find some time. Thanks!

Thanks for adding that enumerate refresh rates option Dege, I am now happily playing carmageddon 2 with my fav refresh rate without a problem!
If it's not too hard to implement, when you have time maybe you can try implementing a borderless window option for a more awesome full screen method?

I spent about an hour with Turok 2 and DGVoodoo 2. It ran and looked great. Very nice work.

Helpful tips - if the retail version of the game won't see the DGVoodoo glide3x.dll, rename Turok2.exe to Turok2english.exe. And to get the CD Audio working there is this MusicEnabler patch (worked for me with Win8).
http://www.mediafire.com/download/5u8ad7uho57 … usicEnabler.zip

And by all means increase the FoV by going into the console (~) and typing "set fov xx" (up to 90).

swaaye wrote:

if the retail version of the game won't see the DGVoodoo glide3x.dll, rename Turok2.exe to Turok2english.exe.

Wrong solution.
The source for this trouble is the system ACT database. It have 2 fixes for the US version of Turok 2: Seeds of Evil. AddWritePermissionsToDeviceFiles and IgnoreLoadLibrary (video_3dfx.dll). The first one is MUST BE for the Securom 1.x. The second one disables the glide renderer.
You must disable an entry for Turok 2: Seeds of Evil in the system ACT database, then create/install an entry with AddWritePermissionsToDeviceFiles only.
P.S. The rename is working only with cracked executables.
P.S.S. Others affected games are: Falcon 4.0, South Park. The fix is similar.

Mr.Deviance wrote:

Thanks for adding that enumerate refresh rates option Dege, I am now happily playing carmageddon 2 with my fav refresh rate without a problem!

Great!!

If it's not too hard to implement, when you have time maybe you can try implementing a borderless window option for a more awesome full screen method?

It's there. Option 'Scaled full screen' is for that. 😀

I spent about an hour with Turok 2 and DGVoodoo 2. It ran and looked great. Very nice work.

Great news!! Thanks!

Dege wrote:

Just released the new version.
Shortly: Turok2 is fixed and possibility of refresh rate overriding is added.

Dege,

I've been trying in vain to get dgv2 2.22, 2.3, 2.31, and 2.32 to run for me under Win8.1.1x64, an HD 7850 2GB, running Catalysts, 13.12, 14.3b, and 14.4b's--with no luck! What happens, specifically in KQ8: MoE, is that Glide is recognized and is configurable via the in-game options screens to 800x600, and when opening a new game or restoring a saved game, the first two loading screens also render properly--then bam!--dgv2 cannot open an actual in-game screen, and I get a black screen. The game is actually running, as the sound track is heard correctly and the game is running and present in the Task Manager, but, again, no D3d-accelerated in-game screen will open. I've moved Glide2x.dll from your 3dfx directory to the KQ8 root, set the KQ8 directory for the dgv2 config file, of course, and I have set up the internal dgV2 configuration in every possible combination in terms of TNU's/ram, etc. Still no game screen will open. Game runs with black screen, sound-track running properly, but after a few keypresses it locks up entirely and the only way out is through the task manager.

I thought at first it might be a simple refresh-rate problem, but, you know, since LCDs have become the norm those kinds of problems (monitor loses sync with the GPU) are much less frequent, at least for me. But enumerating the refresh rates doesn't help, sadly enough (I was hoping it might as the symptoms sure reminded me of losing refresh rate sync!)

dgV2 is well-regarded and many folks really like it and I'd really like to be to use it myself if at all possible...😉 I also like the fact that it can run with svn-daum-dosbox, reportedly, since this is something that the Zeckensack wrapper apparently cannot do (Windows only, IIRC.) I feel as if it's possibly something that *I* am doing wrong running/configuring dgV2, but I just can't think of what it might be. (I really enjoy getting things that should run to run, if you can't tell...😉)

I'm having no difficulties with nGlide 1.03 and as I mentioned Zeck's GW. Thanks much for all of your work and effort--it is much appreciated. Perhaps you have some thoughts on what I might be able to do at my end to achieve a better result! I feel like it's something really simple--but darned if I know what! Thanks much, again, for your efforts!

WaltC

Hi WaltC!

I feel as if it's possibly something that *I* am doing wrong running/configuring dgV2, but I just can't think of what it might be. (I really enjoy getting things that should run to run, if you can't tell...😉)

There is no anything that can be done wrong in regard of dgv2. Dgv2 should work out-of-the-box with any card supporting DirectX 10.1, no additional configuration is needed.
The default config applies a Voodoo2 card with 2 TMUs which is more than enough for vast majority of Glide applications. All the other options are just extras (resolution, msaa, etc.).

I thought at first it might be a simple refresh-rate problem, but, you know, since LCDs have become the norm those kinds of problems (monitor loses sync with the GPU) are much less frequent, at least for me. But enumerating the refresh rates doesn't help, sadly enough (I was hoping it might as the symptoms sure reminded me of losing refresh rate sync!)

I'm sure that it cannot be a refresh-rate problem. In fact, dgv2 cannot drive a monitor at a non-supported refresh rate. If a Glide application requires a refresh rate that is not supported natively then it chooses the "most matching" of the supported ones with additional vsync-handling. But all this is handled by Windows and the driver, not by dgvoodoo.
If you try the game in windowed mode, I bet it will render a blank screen too.

What happens, specifically in KQ8: MoE, is that Glide is recognized and is configurable via the in-game options screens to 800x600, and when opening a new game or restoring a saved game, the first two loading screens also render properly--then bam!--dgv2 cannot open an actual in-game screen, and I get a black screen. The game is actually running, as the sound track is heard correctly and the game is running and present in the Task Manager, but, again, no D3d-accelerated in-game screen will open.

So menu screens are working with dgVoodoo, and it gets broken only when you enters the game?
Pondering on what is the difference between the menuscreens and ingame rendering, I got to the following:
Menu screen uses lfb-locking (2D-style drawing) only while ingame rendering uses 3D rendering too. It seems 3D rendering won't work with your card for some reason. I suspect that one of the shaders simply won't run or won't run correctly and gives a black output. It smells like a driver bug because if the wrapper is able to get into the game then it means that creating all of the shaders succeeds (otherwise it wouldn't even open a Glide session but return an error).

What about other Glide wrapped games? Are they giving a blank screen too?

I feel there is something wrong with Windows8 and ATI cards. Zelibola has permanent driver crashes with Win8 and an ATI card. 🙁

I don't know what to advice you for the moment. The truth is, I never tested dgVoodoo with Win8.
Maybe I could set up a minimal Win8 partition on my HD and try it out with my low-end ATI card with the latest drivers.
The other possibility is using the DX11 debug layer to trace down the bug but it would require you to install Windows8 SDK on your computer and then I could give you a dgVoodoo version using the debug layer. After that, there are basically 2 cases: if the debug layer does not give any warnings, errors, etc (normal case) then there is no any DX11 driving issue and the bug is somewhere the video card driver. However if the debug layer indicated something then we would know, at least, what the problem could be.

Dege wrote:

Hi WaltC!

There is no anything that can be done wrong in regard of dgv2. Dgv2 should work out-of-the-box with any card supporting DirectX 10.1, no additional configuration is needed.
The default config applies a Voodoo2 card with 2 TMUs which is more than enough for vast majority of Glide applications. All the other options are just extras (resolution, msaa, etc.).

Thanks, Dege...;)

That's what I thought--it's a brilliantly simple installation process that should work without difficulty. I prefer your method to a system-wide installation for obvious reasons--but as you say in the read.me, I could make it system-wide if I wanted just by copying the files to the proper folders. But since I don't need to, why bother, right? That's just one of many reasons why this is frustrating for me--I really want to use your program. It's the principle of the thing...;) I know it runs and runs well and so I want to keep working with it until I get it to run for me, too. (Honestly, there are very few things like this that I cannot get to run in the end, so my interest is an abiding one...;))

I'm sure that it cannot be a refresh-rate problem. In fact, dgv2 cannot drive a monitor at a non-supported refresh rate. If a Glide application requires a refresh rate that is not supported natively then it chooses the "most matching" of the supported ones with additional vsync-handling. But all this is handled by Windows and the driver, not by dgvoodoo.
If you try the game in windowed mode, I bet it will render a blank screen too.

That is correct...it's obviously not refresh. It behaves like a refresh problem (black screen while game runs in background), but it isn't. Well, it was worth a guess...;)

So menu screens are working with dgVoodoo, and it gets broken only when you enters the game?
Pondering on what is the difference between the menuscreens and ingame rendering, I got to the following:
Menu screen uses lfb-locking (2D-style drawing) only while ingame rendering uses 3D rendering too. It seems 3D rendering won't work with your card for some reason. I suspect that one of the shaders simply won't run or won't run correctly and gives a black output. It smells like a driver bug because if the wrapper is able to get into the game then it means that creating all of the shaders succeeds (otherwise it wouldn't even open a Glide session but return an error).

Yep! It's choking on the 3d-rendered in-game itself, whereas the 2d menus (D3d software) are displaying perfectly.

What about other Glide wrapped games? Are they giving a blank screen too?

With dgV2, yes, unfortunately. nGlide and Zeckensack's seem to work without difficulty (Zeckie's won't work with dosbox/nGlide will--dgv2 works with both--if I could get it running.) If it was just a matter of simply playing a game I'd just be happy with the other wrappers, of course. But, it seems to me that you've done a lot of nice work with your wrapper, and other folks are reporting very good results with it, so it has become something I really want to get up and running...(I get obstinate that way...;))

I feel there is something wrong with Windows8 and ATI cards. Zelibola has permanent driver crashes with Win8 and an ATI card. […]
Show full quote

I feel there is something wrong with Windows8 and ATI cards. Zelibola has permanent driver crashes with Win8 and an ATI card. :(

I don't know what to advice you for the moment. The truth is, I never tested dgVoodoo with Win8.
Maybe I could set up a minimal Win8 partition on my HD and try it out with my low-end ATI card with the latest drivers.
The other possibility is using the DX11 debug layer to trace down the bug but it would require you to install Windows8 SDK on your computer and then I could give you a dgVoodoo version using the debug layer. After that, there are basically 2 cases: if the debug layer does not give any warnings, errors, etc (normal case) then there is no any DX11 driving issue and the bug is somewhere the video card driver. However if the debug layer indicated something then we would know, at least, what the problem could be.

It could well be some peculiarity with Win8.1.1x64 (the number conventions for 8 have gotten silly--what was wrong with NT6.3, etc.?), no doubt about it. I'm also running the June 2012 version of DX9.0c, a version of DX7.a that actually installs, and the DX SDKs for 2008 & 2010 just for the sake of backwards compatibility. Overall, backwards compatibility with Win8 thus far is excellent--easily as good if not actually a bit better than it was with Win7x64. All of my dosbox svn-daum games run in direct 3d (software) mode without a problem, which allows me to use shaders with them like HQ2x.fx, etc., which actually improves the display of the older games compared to what can be done with overlay or surface, and so on. I don't use touch and I don't use "Metro" or whatever they call it--I use 8 with the explorer.exe ui--which is the best way to run it, imo! (Maybe some of this information might be of value to you, possibly...;) )

And, yes, there may be some oddities as to how AMD structures its D3d drivers--I've noticed that I cannot run Wine ddraw.dll's (installed to the game directories, of course) in order to aid backwards compatibility with a couple of older games, while folks running nVidia hardware don't have a problem doing so--don't really know what to think about that.

Thanks much for your time in thinking about this, Dege. Maybe I'll eventually be able to use dgV2! Thanks again.

I have been playing Turok 2, NFS4 and Klingon Honor Guard with dgvoodoo2 on Win8.1 and with a Radeon 6950. No strange problems.

Turok 2 was showing only 2D elements and had blank 3D before dege fixed it up.

That's just one of many reasons why this is frustrating for me--I really want to use your program. It's the principle of the thing...😉 I know it runs and runs well and so I want to keep working with it until I get it to run for me, too.

Man, you really seems to be a big fan of this wrapper! 😁 Thanks.

Yep! It's choking on the 3d-rendered in-game itself, whereas the 2d menus (D3d software) are displaying perfectly.

Let's wait a minute! KQ's 2d menus are rendered with either DirectDraw or Glide. If you select 3Dfx Glide in the Graphics submenu for the rendering then it switches to that immediately so you cannot enter from DDraw 2D to Glide ingame. I mean, it seems that 2d rendering works for you with dgvoodoo2.

Overall, backwards compatibility with Win8 thus far is excellent--easily as good if not actually a bit better than it was with Win7x64. All of my dosbox svn-daum games run in direct 3d (software) mode without a problem, which allows me to use shaders with them like HQ2x.fx, etc., which actually improves the display of the older games compared to what can be done with overlay or surface, and so on. I don't use touch and I don't use "Metro" or whatever they call it--I use 8 with the explorer.exe ui--which is the best way to run it, imo!

Yes, I have no doubt about that Win8 is basically a good system. I just don't like its look that's why I haven't upgraded. I don't like this forced integration of desktop and tiled metro UI and the lack of nice aero glass window borders. Also, each time I wanted quickly to click on the start button on Win8, I always felt as if I wanted to spring up from the chair but suddenly realized that I had no legs. 😀

I'm also running the June 2012 version of DX9.0c, a version of DX7.a that actually installs, and the DX SDKs for 2008 & 2010 just for the sake of backwards compatibility.

Starting from a Windows update, DirectX SDK became part of the Windows7 (or 8?, can't remember now) SDK. I myself also used the old 2010 June version, it was the latest substantive version. But then a Windows update came and the DX11 debug layer didn't work anymore with that SDK version (not to mention DX9 64bit debugging) so I had to install the latest Windows SDK to get it to use again... 😒

I think I'm going to compile a debug version of dgvoodoo using the DX11 debug layer. And then, by running DebugView, you could send me back the debug output to see what happening.

It could well be some peculiarity with Win8.1.1x64

And, yes, there may be some oddities as to how AMD structures its D3d drivers--I've noticed that I cannot run Wine ddraw.dll's (installed to the game directories, of course) in order to aid backwards compatibility with a couple of older games, while folks running nVidia hardware don't have a problem doing so--don't really know what to think about that.

I think that there is a small bug somewhere in the ATI drivers but it works well generally with other applications otherwise. So it can be treated as a dgVoodoo problem. One ATI bug was revealed when I first tried this wrapper on ATI: GPU queries does not survive buffer swapping while it worked well with nVidia and Intel.
For the moment my 3D pixelshaders are the suspect. I don't know why but it seems as if the ATI driver (a given version, or for a given chip architecture) couldn't translate their bytecode to its own form and they didn't run. They are too long, or something...

Turok 2 was showing only 2D elements and had blank 3D before dege fixed it up.

That was just a little z-buffer problem. The game used wrong default value for clearing the z-buffer because of a buggy query from Glide. So, I had to only modify a number, everything else worked right. 😀

Dege wrote:

Man, you really seems to be a big fan of this wrapper! 😁 Thanks.

Of course I am...😉 How could I *not* be? You've gone to the trouble to write the wrapper and are still supporting it, so I think it would be very rude of me *not* to be a fan!...😁 I've corresponded with many folks who like dgV2 a lot and they've got me itching to to get it running. Thanks to you for taking the trouble and time to write and support the wrapper! I well remember those days when *all* my 3d games were Glide games and when the boxed screen shots were also grabbed from Glide. In one sense it seems like yesterday--in another, like ancient history...😉 I think these wrappers are important! (And I just like having them around!)

Let's wait a minute! KQ's 2d menus are rendered with either DirectDraw or Glide. If you select 3Dfx Glide in the Graphics submenu for the rendering then it switches to that immediately so you cannot enter from DDraw 2D to Glide ingame. I mean, it seems that 2d rendering works for you with dgvoodoo2.

Yes! Bad choice of words on my part--I should've said Glide software mode (2d)...😉 Yes, the 2d rendering when running in Glide renders exactly as it should under all the versions of dgv2 I've tested.

Yes, I have no doubt about that Win8 is basically a good system. I just don't like its look that's why I haven't upgraded. I don't like this forced integration of desktop and tiled metro UI and the lack of nice aero glass window borders. Also, each time I wanted quickly to click on the start button on Win8, I always felt as if I wanted to spring up from the chair but suddenly realized that I had no legs. 😀

No kidding! I really didn't think I was going to miss the start menu--that really makes me laugh at myself, as I turned out to really miss it--that vertical/side-scrolling monstrosity called a "start screen" with its dumbed-down options and so much wasted screen real estate made me *nuts* to get back the simplicity of the start menu--from which I could do *everything* I wanted from a single page--the desktop--no scrolling required. The start "screen" (that really should be plural) is just a hideous desktop, imo...😉 Classic Shell version 4.04 works really well with 8.1.x, though, and allows me to to turn off all the "charms" and hotspots, if I want (I want.) I leave the "start screen resident but I never actually use it for anything. (I'll have to think about why I'm doing that.)

This has got to be really embarrassing for Microsoft... Latest '014 spring update blog I read from them explicitly states they are bringing the start menu back to *8* RSN. Yea, great--but why have they taken so long? I'm sure you've noticed all the musical chairs going around inside the company--with the people at the very top who green-lighted Win 8's "Modern" or "Metro" or whatever they want to call the touch ui--now either permanently gone from the company (Sinofsky) or else banished to quarterly board meetings (Ballmer.) Also, Gates is coming back in a day-to-day capacity as "assistant" to the new CEO. Interesting times--but at least they aren't waiting until "Windows 9" to put a start menu back in for those of us who want it. Or, so they say. We'll see, right?

One thing I do like a lot about Win8 is the built in mounting of .iso's. Doesn't sound like a big deal, but really it is transparent in use--just right-click for a context menu on any .iso file and the first option available is mount....😉 It works really well and truly brings out the kludginess of Daemon tools, imo (which I had used since way back for the same purpose.) You can mount the .iso and run it--just as if it was a physical disk in a drive, install from it, etc. That's one other thing I didn't think would amount to much with Win8, but from which it turns out I get a lot of use! Go figure! (I wonder if I know my own computing habits as well as I think I do, sometimes...😉)

Anyway, if Microsoft ever gets 8 right so that it will appeal to us high-density mouse & keyboard folks (probably, oh, what, 95% of Microsoft's current installed Windows base?), it might just start selling much better. I prefer it to 7x64, but that's only after I worked to make it fit my habits and preferences--and I do think it was worth the $39.99 I paid to buy the Pro upgrade from 7x64, direct from Microsoft when they had that introductory sale for Win8! But compared to Win7 overall, I don't think it's worth another *penny* beyond that $39.99 price I paid for it back in Jan of '13...😁

They've done some weird stuff all around in '013. Lots of weirdness about giving folks stand-alone .iso images of Win8/8.1, too--want folks to go through that horrid Windows store mess...! Arghhhh, but that is awful. Anyway--I've gotten legitimate .iso's for 8 through Technet and then 8.1 through MSDN--but why Microsoft wants to make that so convoluted for its regular audience and market beats me!

OK, 'nuff said I guess about Win8. I like it a bit better than 7, but with several caveats, as you can see...!

Starting from a Windows update, DirectX SDK became part of the Windows7 (or 8?, can't remember now) SDK. I myself also used the old 2010 June version, it was the latest substantive version. But then a Windows update came and the DX11 debug layer didn't work anymore with that SDK version (not to mention DX9 64bit debugging) so I had to install the latest Windows SDK to get it to use again... 😒

Thanks for the info--I *always* enjoy hearing about details like this!

I think I'm going to compile a debug version of dgvoodoo using the DX11 debug layer. And then, by running DebugView, you could send me back the debug output to see what happening

It'd be my pleasure. Let me know when and what.

I think that there is a small bug somewhere in the ATI drivers but it works well generally with other applications otherwise. So it can be treated as a dgVoodoo problem. One ATI bug was revealed when I first tried this wrapper on ATI: GPU queries does not survive buffer swapping while it worked well with nVidia and Intel.
For the moment my 3D pixelshaders are the suspect. I don't know why but it seems as if the ATI driver (a given version, or for a given chip architecture) couldn't translate their bytecode to its own form and they didn't run. They are too long, or something...

Sounds very good! I remember way back in '02-'03 that ATi talked about using the maximum instruction length permitted by the early shader models, but don't know if that would have any bearing here, of course.

Thanks for the interesting conversation, Dege, and as I say, if you're game then I'll be happy to help any way I can!

Remember Carmageddon had a physics bug with the older dgvoodoo (first snow level had poles you could push over but it was broken with dgvoodoo. Poles would remain stationery and solid). Is this fixed?