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--

Yes, it is! I'm curious about (and waiting for) Windows 9. 😀

As for the debugging stuff:

If I think into it better, I don't need to compile a separate version for using the debug layer.
It can be forced through the DirectX control panel (part of the SDK).

So, through the DirectX control panel (32 bit) on the Direct3D10.x/11 tab you can set the debug layer usage to 'Force On' and select the glide wrapped exe's folder into the list of affected executables, see the attached image.

And then, launch DebugView (if you don't want to attach to the process by Visual Studio):

http://technet.microsoft.com/en-us/sysinterna … s/bb896647.aspx

It displays debug outputs coming from any application.
If all that set up, then start the glide application, get to the point where it does not work and see the output of DebugView. DX11 debug layer outputs a lot of info, warnings and errors if any detected.

I think it's important to use the DX Debug layer and the Control Panel from the latest SDK because older version won't work with Win8 (the debug layer simply won't be forced to be injected between the glide wrapper and the DX runtime):

http://msdn.microsoft.com/en-us/library/windo … v=vs.85%29.aspx

Just to correct myself, 64 bit DirectX9 has gone wrong by the Windows update (Win7 SP1 I think) and the DX SDK integrated into the Win SDK, that I mentioned. 64 bit DirectX9 control panel does not work anymore by default with the latest SDK. A manual hack in the registry is needed to get it to work:

http://www.gamedev.net/topic/649179-windows81 … -control-panel/

But this does not affect dgVoodoo, just mentioned as I was suffering agonies from this at my workplace. 😀

Holering wrote:

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?

Umm, I don't know. I think if Carma works properly with Dosbox then it should also work well with dgVoodoo2 with Dosbox.
Should try it.

Dege wrote:

...As for the debugging stuff:...

Good deal! Get back here in a few, after I wrap up some of the other stuff I have to get done...!

I'm Back!!!! I am appending the log file...I think this will be of some value!

Dege,

I realized on the first debugging run that I had left on the "Mute Severity of the Info" in the DX ctrl panel (I had left it checked) so I ran the game again this time with no info muted...result is attached here--did not comment on this one since you'll by now see what's going on in the first. Not a great deal of difference between the two debug files, except during the time the screen goes to black and the game eventually locks, this log is a bit more informative, I think. Here it is--hope it helps!

Walt, huge thanks for the log!!

I've just browsed it and found many lines complaining of errors but the root of them is the following:

D3D11 ERROR: ID3D11DeviceContext::Map: Returning DXGI_ERROR_DEVICE_REMOVED, when a Resource was trying to be mapped with READ or READWRITE. [ RESOURCE_MANIPULATION ERROR #2097214: RESOURCE_MAP_DEVICEREMOVED_RETURN]

D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]

So, the thing is as follows:

- Zelibola has an ATI HD7970
- You have an ATI HD7850,

and the driver crashes or gets into an infinite loop for some reason for both of you. Seems it is something related to the drivers of the HD 7xxx series 🙁
I'm sure that it's a bug in the driver. When I started to develop dgV2, I run into a similar situation with my nVidia cards. Everything worked OK on the Intel HD2000 but I got random but permanent crashes (TDR detecting infinite loop) with any nVidia cards if I played a game using z-buffer. Finally I traced the bug down, the driver did not like when two different rendertarget view with different formats were created for a texture, in spite of the DX11 API allows that (as it worked fine on Intel). I workarounded it and didn't reported the error to nVidia, but it was very frustrating.

I think if we could reproduce the same with a very simple example application, say one of the 3Dfx SDK examples, or one written by me doing nothing just drawing a triangle, I could send it to the ATI error report system (I hope there is something like that) and could expect ATI to fix it.

Dege wrote:

Walt, huge thanks for the log!! […]
Show full quote

Walt, huge thanks for the log!!

I've just browsed it and found many lines complaining of errors but the root of them is the following:

D3D11 ERROR: ID3D11DeviceContext::Map: Returning DXGI_ERROR_DEVICE_REMOVED, when a Resource was trying to be mapped with READ or READWRITE. [ RESOURCE_MANIPULATION ERROR #2097214: RESOURCE_MAP_DEVICEREMOVED_RETURN]

D3D11 ERROR: ID3D11Device::RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]

So, the thing is as follows:

- Zelibola has an ATI HD7970
- You have an ATI HD7850,

and the driver crashes or gets into an infinite loop for some reason for both of you. Seems it is something related to the drivers of the HD 7xxx series 🙁
I'm sure that it's a bug in the driver. When I started to develop dgV2, I run into a similar situation with my nVidia cards. Everything worked OK on the Intel HD2000 but I got random but permanent crashes (TDR detecting infinite loop) with any nVidia cards if I played a game using z-buffer. Finally I traced the bug down, the driver did not like when two different rendertarget view with different formats were created for a texture, in spite of the DX11 API allows that (as it worked fine on Intel). I workarounded it and didn't reported the error to nVidia, but it was very frustrating.

I think if we could reproduce the same with a very simple example application, say one of the 3Dfx SDK examples, or one written by me doing nothing just drawing a triangle, I could send it to the ATI error report system (I hope there is something like that) and could expect ATI to fix it.

Dege,

Thanks so much for taking a look! Ah, well, such is life...😉 It was worth a shot, anyway. Yes, I had noticed (now that I think about it) that the Catalysts had crashed and then self-reset a couple of times when running the game with dgV2 (the Catalysts display a large message when that happens but it had been so long since I'd seen it I had forgotten about that, too), so I guess that's just the way things stand at the moment. There are maybe one or two minor things percolating in the back of my head about workarounds having to do with possibly conflicting pieces of software I'm running but had forgotten about--like a utility called "Radeon Pro" that also runs a service by just being installed--meant to uninstall that long ago, but hadn't. But I don't see much probability there, frankly. Thanks again, though, and if I should stumble into anything that makes a difference, I'll surely let you know!

I've still got nGlide 1.03 & Zeckensack's to fall back on, though, so I guess I'll just have to make do...😉 I did want to collect them all, though...😉 Pleasure speaking with you, Dege, and thank you again!

Ah, well, such is life...😉 It was worth a shot, anyway. Yes, I had noticed (now that I think about it) that the Catalysts had crashed and then self-reset a couple of times when running the game with dgV2 (the Catalysts display a large message when that happens but it had been so long since I'd seen it I had forgotten about that, too), so I guess that's just the way things stand at the moment. There are maybe one or two minor things percolating in the back of my head about workarounds having to do with possibly conflicting pieces of software I'm running but had forgotten about--like a utility called "Radeon Pro" that also runs a service by just being installed--meant to uninstall that long ago, but hadn't.

Not problem. At least it cleared up by the log. 😀

But I don't see much probability there, frankly.

I think (or, feel) it's a core driver bug, but I don't know if dgvoodoo crashes on all ATI HD7xxx.
Shouldn't give the bug reporting a go? 😀
I found ATI's bug report form:
http://www.amdsurveys.com/se.ashx?s=5A1E27D20B2F3EBB

What if I whip up a simple glide application doing nothing but rotating a triangle and see if it crashes on your computer? 😀
If it does then I could zip up the glide dll and the application and give it to ATI as a simple repro pack.
Who knows, maybe they find something and fix that in the next Catalyst release. 😁

Dege wrote:

xxx. Shouldn't give the bug reporting a go? :happy: I found ATI's bug report form: http://www.amdsurveys.com/se.ashx?s=5A1E27D2 […]
Show full quote

xxx.
Shouldn't give the bug reporting a go? 😀
I found ATI's bug report form:
http://www.amdsurveys.com/se.ashx?s=5A1E27D20B2F3EBB

What if I whip up a simple glide application doing nothing but rotating a triangle and see if it crashes on your computer? 😀
If it does then I could zip up the glide dll and the application and give it to ATI as a simple repro pack.
Who knows, maybe they find something and fix that in the next Catalyst release. 😁

Sure...that would be fun...! Attach away...😉

Hey Dege, any chance you can take a crack at the videos on KQ8 in fullscreen? For example, the intro video will play correctly in windowed mode with ddraw.dll but not in full-screen (you get audio but the screen stays black). I'm using Windows 8.1 x64/x86 and Win 7 x64 as my test cases.

arablizzard2413 wrote:

Hey Dege, any chance you can take a crack at the videos on KQ8 in fullscreen? For example, the intro video will play correctly in windowed mode with ddraw.dll but not in full-screen (you get audio but the screen stays black). I'm using Windows 8.1 x64/x86 and Win 7 x64 as my test cases.

I didn't know about that but yes, I will examine that.
I guess videos don't work at all with my ddraw then, because KQ has its own mechanism for switching between fullscreen/windowed mode by Alt-Enter.
KQ uses simple software rendering through into the window with GDI, for its own windowed mode that's why it works.
(If you can't see the "dgVoodoo" logo then it's probably not rendered through dgVoodoo. 😀 )

Had to test it again today since I was writing from memory. So when the mode is set to Windowed, it will switch fullscreen with the logo in the bottom right corner of the screen (rest of the screen black). When you uncheck Application controlled fullscreen/windowed state under directdraw then you see the logo for a brief second and the video shows up. No video when set to fullscreen for both.

Waltc wrote:

Dege wrote:

xxx. Shouldn't give the bug reporting a go? :happy: I found ATI's bug report form: http://www.amdsurveys.com/se.ashx?s=5A1E27D2 […]
Show full quote

xxx.
Shouldn't give the bug reporting a go? 😀
I found ATI's bug report form:
http://www.amdsurveys.com/se.ashx?s=5A1E27D20B2F3EBB

What if I whip up a simple glide application doing nothing but rotating a triangle and see if it crashes on your computer? 😀
If it does then I could zip up the glide dll and the application and give it to ATI as a simple repro pack.
Who knows, maybe they find something and fix that in the next Catalyst release. 😁

Sure...that would be fun...! Attach away...😉

As a post script for the teeming throngs no doubt hanging on every word of our engaging conversation here...😉...thanks to Dege we have isolated the problem and the bug is winging its way to ATi where hopefully it will be addressed...! No doubt it's something in the Catalysts. Thanks again, Dege! (Who says chasing bugs can't be fun and engaging?)

arablizzard2413 wrote:

Had to test it again today since I was writing from memory. So when the mode is set to Windowed, it will switch fullscreen with the logo in the bottom right corner of the screen (rest of the screen black). When you uncheck Application controlled fullscreen/windowed state under directdraw then you see the logo for a brief second and the video shows up. No video when set to fullscreen for both.

I've just tried it. Now I see the phenomenon and also understand why it is.
The bad news is that it's a GDI/DDraw interact issue again. The game uses DDraw only to set the resolution and then the video codec renders into the window through GDI.
So, when the game is running in windowed mode then the output of codec shows up in the window but there is no logo because it bypasses dgVoodoo. However in fullscreen the video does not show up because the content of the window is suppressed by dgVoodoo's (blank) swapchain.

The only way to fix these cases (I think it's a general problem, there are a lot of game using video codecs to play videos) is to wrap getting/releasing window DCs somehow. 😒

Dege wrote:

Thanks Leileilol. I had a look on PowerSGL SDK and it seems its driver has two main components, a lowlevel PowerSGL Direct, and a high level PowerSGL. I'm not sure which one was primarily used by the applications, but the high level one seems a bit huge library with a lot of software based utility functions (according to the sdk, high level is not built on top of the low level one).
One worrisome thing is that both of them should be implemented and there would be no reference for testing: either an old PowerVR hw or the source of the drivers would be needed. 😐

PowerSGL was published first, PowerSGL Direct later. This is why Mechwarrior 2 which was ported rather early uses PowerSGL while some or all of the later games use PowerSGL Direct. (I suppose the difference is similar to D3D retained and immediate mode so everybody would have used PowerSGL Direct as soon as it was available.) And then there is of course Tomb Raider 1 which runs in DOS and accesses the PowerVR chip directly (hard-linked library) but this is out of scope here.

Regarding a reference for testing: Maybe the MiniGL wrapper (or the Techland wrapper) for PowerVR could be helpful. I don't know if it uses PowerSGL, PowerSGL Direct or even direct hardware access, maybe Dependency Walker or other tools could show that info.

Just a small question.
How do you use dgVoodoo with the 64 bit build of dosbox?
is there a 64 bit dll hiding somewhere? 😜 (because there is a glide2x_64.dll in dosbox folder (ykhwong's Daum version)...

rallymoose wrote:

How do you use dgVoodoo with the 64 bit build of dosbox?

Well, I guess there is no way to use dgVoodoo with 64bit DosBox. A 64bit build of glide2x.dll is needed, I think.

rallymoose wrote:

is there a 64 bit dll hiding somewhere? 😜 (because there is a glide2x_64.dll in dosbox folder (ykhwong's Daum version)...

No, it's not hiding yet, but I could compile a 64bit one. 😀 Glide2x_64 is probably the 64bit version of OpenGlide.
However I'm not sure if it makes sense. AFAIK 64 bit DosBox is slower than 32 bit and compiled binaries are unavailable for download.

Thanks for the info, idspispopd!

PowerSGL was published first, PowerSGL Direct later. (I suppose the difference is similar to D3D retained and immediate mode so everybody would have used PowerSGL Direct as soon as it was available.

I guess the same but I think that the fact PowerSGL was published first implies that it drives the hw directly. So, there we have two driver components driving the hw, unlike DirectX Immediate/Retained. If PowerSGL relied on PowerSGL Direct then reimplementing PowerSGL Direct would be enough.

Trying to use 2.32 with the GOG version of Sin. I've removed the nGlide DLLs from the game directory and replaced them with the dgVoodoo 2 DLLs and setup utility.

When I try to launch the game, it closes itself after I enter my player name. Anyone know why this might be happening?

The game works fine with nGlide.

Probably some initialization screwup. It literally does a vid_restart to your preferred mode or whatever after logging in. I've had this mess up on an actual Voodoo2 before where it would lead to the DOS text mode displaying 2 screen buffers of the Sin menu

Dunno why you want to run Sin in a Glide wrapper though, it's totally a native OpenGL game and I believe the only 3dfx extension it uses is WGL_3DFX_gamma_control

Supposedly it works better under Glide, to the point that GOG ships it with nGlide v0.99 by default.

Edit: The only other thing I can think of is that maybe it's a wacky way for GOG to work around the lack of OpenGL extension limits on some modern drivers?