Dege, sorry to say, but it doesn't work. Launched Sub Culture and Summoner fullscreen and windowed - no luck. Same message about video driver restart.

Well, not too surprising after all... 😀
Thanks for the test!

Browsing on google I read many complains (1-2 years old) of HD 7970 crashing with certain drivers or games.
Does any other DX11 stuff work with your card?
It's also strange that you get only 20-30fps with old DX games.

Dege wrote:

Does any other DX11 stuff work with your card?

Sure it does 😀 But it really strange, what I am first who told you about such thing. Maybe something is wrong with my OS after all. Think I tried everything: different gfx drivers, unloaded all D3D hooks like MSI Afterburner even underclock whole system. Got to try old Windows 7 image. Thanx anyway, Dege.

The Glide Wrapper works great with many of the games I've tried it on, and the DirectDraw wrapper worked on MTM2, but it turns out the DirectDraw wrapper doesn't yet seem to work with Hellbender, as it doesn't detect a 3D Accelerator. Any way this could be fixed?

Here's a link to the Trial Version, which should suffice. https://docs.google.com/file/d/0B5wxdPnZcqXjb … mNoNF8wc3M/edit

Just click file -> Download.

1. Direct3D is not Glide.
2. Hellbender uses table fog - a feature not supported on modern hardware. Game will be unplayable in Direct3D if it 'worked'.
3. The Microsoft FTP still hosts the trial version

leileilol wrote:

1. Direct3D is not Glide.
2. Hellbender uses table fog - a feature not supported on modern hardware. Game will be unplayable in Direct3D if it 'worked'.
3. The Microsoft FTP still hosts the trial version

1. I know that, never said they were one and the same. However, it would appear that dege is also working on a Direct3D/DirectDraw wrapper as well, not just Glide. See: http://dege.freeweb.hu/

2. That's where the new wrapper could come into play. Table fog could be emulated through Shaders, could it not? (Also, older NVidia drivers had the ability to enable table fog *emulation*. For example, when I had my 9800GT, which lacked support for table fog natively, older drivers emulated Table fog and it worked great, but after a later driver release, support for it got dropped, and everything began to behave exactly like the later cards I've owned. It happened around when the 154.xx drivers were replaced I do believe.)

3. The Microsoft FTP is dead, try visiting it, it won't work. (I just tried to connect to it, both via my browser, and my FTP Client, neither work and say the host is not found.)

StrikerMan780 wrote:

The Glide Wrapper works great with many of the games I've tried it on, and the DirectDraw wrapper worked on MTM2, but it turns out the DirectDraw wrapper doesn't yet seem to work with Hellbender, as it doesn't detect a 3D Accelerator. Any way this could be fixed?

Here's a link to the Trial Version, which should suffice. https://docs.google.com/file/d/0B5wxdPnZcqXjb … mNoNF8wc3M/edit

Well, "fixing" it would mean implementing Direct3D COM interfaces too, not just DirectDraw as it is now.
It wasn't my goal, - creating a DDraw wrapper is for using 3Dfx OpenGL on top dgVoodoo, which is still pending and in progress (but paused now)- but it could be done.

I was thinking on that earlier, all the D3D interfaces up to D3D7 with fixed function pipeline could be emulated through shaders, exposing the capabilities of a contemporary nVidia or ATI card, I think. It would be nice.
The problem is, I would have to implement D3D, D3D2, D3D3, D3D5, D3D6, D3D7 along with all features the software-based fixed function vertex pipeline provides. 😀
Of course they have a lot of common but each of them would have to be reverse-engineered for potential specific way of working (as it was done with DDraw interfaces).

2. That's where the new wrapper could come into play. Table fog could be emulated through Shaders, could it not?

Yes, it could. Tabled fog in Glide is already emulated in the pixel shader.

EDIT: Anyway, D3D does not support table fog, but only parametrized linear, exp, square exp fog-functions that were implemented by fogtabling on old hardware. However it could be computed directly in a shader, without a table.

StrikerMan780 wrote:

1. I know that, never said they were one and the same. However, it would appear that dege is also working on a Direct3D/DirectDraw wrapper as well, not just Glide. See: http://dege.freeweb.hu/

Well, DirectDraw maybe, but that does not imply Direct3D. Maybe someday...

There are several DirectDraw wrappers out there, dege has made another one in dgVoodoo 2.3.

From dgVoodoo 2.3 readme.txt:

10. DirectDraw -------------- […]
Show full quote

10. DirectDraw
--------------

First of all: NEVER COPY DDRAW.DLL INTO SYSTEM FOLDERS!! ALWAYS USE A LOCAL
INSTALLATION FOR A GAME! DirectDraw is a still existing and widely used system
component in Windows.

Implementing DirectDraw has two reasons:
- Just to see if I'm capable of doing that. Well, not too shiny results I got.
- Using original 3Dfx OpenGL drivers on top of dgVoodoo.

None of the above makes sense, it's just kind of mental sporting.
Due to lack of time this first DDraw implementation is not full and 3Dfx OGL
drivers still cannot be used on top of this version of dgVoodoo. I need to solve
2 problems to (hopefully) use that with dgVoodoo.

Any components of dgVoodoo can be used together within an application (process),
so Glide and DirectDraw can co-work for games. This brings in some slight good
things. For example, a few games initializes DirectDraw at startup which prevents
Direct3D (in the Glide renderer) to work (at all or properly). If real DirectDraw
is suppressed by dgVoodoo's own one this is not a problem anymore. So that,
Esoteria now works beautifully and NFS3 Hot Pursuit can be played in real
fullscreen mode without applying any game patches. But, DirectDraw can be used
in a standalone way of course, to play a DirectDraw-only game.
Controlling fullscreen/windowed rendering state is part of the DirectDraw API
so forcing it is disabled by default.

As I mentioned, this DDraw implementation is not finished and may contain bugs
I know of, but forgot to fix. Also, while reverse engineering, I discovered that
I was facing problems similar to Glide: some bad-written game code violate DDraw
rules and works only by chance. I tried to workaround most of them but not all
of them could be workarounded. The only way is like MS does it: turn off DWM
and give full control to the application...
Also, some application try to create a 3D interface on top of DirectDraw even
if it is not used at all. Since there is no any version of Direct3D interfaces
implemented in dgVoodoo, those applications won't work.

So, don't expect too much of this version. I tested it with the followings:

- One of my old DDraw intro
- My DDraw test programs
- Tarzan
- Need For Speed II
- Need For Speed III HP
- Esoteria
- Outlaw demo
- Powerslide demo
- Subculture
- KQ: Mask Of Eternity
- Ignition
- Some other games that do not work well with it. The base problem is that
native DirectDraw can co-operate with GDI and this behavior cannot be
fully emulated through D3D11. In some cases forced windowed mode helps
but then why not to use native DirectDraw?
- ? can't remember more

I have a short list of Direct3D-to-Direct3D wrappers, it includes:
EnbConvertor DX8-DX9 (obvious) - http://enbdev.com/download_convertor_dx8todx9.htm
AnKor's DirectX 8 to DirectX 9 Converter - http://simhq.com/forum/ubbthreads.php/topics/ … converter_updat

Some other cool hacker things:
Re: dgVoodoo 2 for DirectX 11

StrikerMan780 wrote:

2. That's where the new wrapper could come into play. Table fog could be emulated through Shaders, could it not? (Also, older NVidia drivers had the ability to enable table fog *emulation*. For example, when I had my 9800GT, which lacked support for table fog natively, older drivers emulated Table fog and it worked great, but after a later driver release, support for it got dropped, and everything began to behave exactly like the later cards I've owned. It happened around when the 154.xx drivers were replaced I do believe.)

That would be something but I wouldn't hold your breath. That's a TON of work, and Windows does not act kindly towards Direct3D being hacked out underneath it. Some people have said in the past that DirectX 7 wrapping is, in fact, an impossibility.
The most likely projects that will result in what you want is DXGL and WineD3D (both of which wrap to OpenGL) and it may be quite a while before you see decent Direct3D-related results there, especially using shaders.

If any new wrappers are to be authored, I personally would love to see another obscure proprietary API wrapped, like PowerVR SGL or S3 Toolkit, for which we have (at least) the SDKs (though not the sourcecode to the SDK/libraries).

StrikerMan780 wrote:

3. The Microsoft FTP is dead, try visiting it, it won't work. (I just tried to connect to it, both via my browser, and my FTP Client, neither work and say the host is not found.)

No problems here. Maybe you have DNS issues.

Some people have said in the past that DirectX 7 wrapping is, in fact, an impossibility.

Uhm, I think one of those was me... 😀
Ok, I don't think that old D3D interfaces are actually wrapped, probably the video drivers must support the old D3D DDI interfaces even in a WDDM environment. Which means that if a hw feature is dropped then it is exposed through the old D3D caps bits, so that old games will be starting not to work properly in the future.
(Actually, nVidia did that with w-buffering, I was very sad back then.)
But now I do think that old D3D interfaces could be wrapped. I just thought MS already did that because MS is a kind of a software developer company who keeps binary and API-compatibility at a quite high level (unlike others) and some of their own APIs are already been wrapped by themselves.

If any new wrappers are to be authored, I personally would love to see another obscure proprietary API wrapped, like PowerVR SGL or S3 Toolkit, for which we have (at least) the SDKs (though not the sourcecode to the SDK/libraries).

Stiletto, maybe it's a silly question, but would it worth to create a wrapper for those APIs? Were they so popular and prevalent to worth to deal with them?

Dege wrote:

Stiletto wrote:

If any new wrappers are to be authored, I personally would love to see another obscure proprietary API wrapped, like PowerVR SGL or S3 Toolkit, for which we have (at least) the SDKs (though not the sourcecode to the SDK/libraries).

Stiletto, maybe it's a silly question, but would it worth to create a wrapper for those APIs? Were they so popular and prevalent to worth to deal with them?

vetz has done a tremendous job of documenting it here:
3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)
PowerVR (PowerSGL): 11 exclusive games, 40 non-exclusive games
S3 Virge (S3D): 5 exclusive games, 14 non-exclusive games
*3D Blaster (CGL): 3 exclusive games, 10 non-exclusive games
Nvidia NV1 (NVLib): 3 exclusive games, 3 non-exclusive games
ATI 3D Rage (ATI CIF): 2 exclusive games, 11 non-exclusive games
*Matrox Mystique (MSI): 2 exclusive games, 10 non-exclusive games
Rendition Verite (RRedline): 1 exclusive game, 11 non-exclusive games
*Rendition Verite (Speedy3D): 1 exclusive game, 10 non-exclusive games
*(SDKs not yet available: CGL, MSI, Speedy3D)

Oh, the usual arguments: preserve every bit, emulate all the old games etc.
You'd have to ask swaaye, vetz, leileilol, etc. what they think...
But also important is "it's never been done before"

But of course, no point suggesting it if you're not interested.
Of course DirectDraw/Direct3D wrapper would have much bigger impact.

Oh, the usual arguments: preserve every bit, emulate all the old games etc.
You'd have to ask swaaye, vetz, leileilol, etc. what they think...
But also important is "it's never been done before"

Hmm, I like doing something only "l'art pour l'art". 😀
So, preserving the old world in an (khm.. perfectly) emulated form for our grandchildren is usually an enough argument for me. (like a Matrix with a 19th century world)
I was just curious how they compare to Glide, for example.

But of course, no point suggesting it if you're not interested.
Of course DirectDraw/Direct3D wrapper would have much bigger impact.

Unfortunately it's all about free time: I wish I could deal with them in full time job.

Alright, thanks for the clarification. I originally thought that some Direct3D 2-6 emulation was in the works as well since the games that used it at the time made calls to ddraw.dll. (Hellbender uses the version of Direct3D that came with DirectX 2.0 in hardware mode, in software, it uses DirectDraw, both from the same DLL.)

Though, on that note, is it normal that the software mode to show up black with that wrapper?

Dege wrote:

I was just curious how they compare to Glide, for example.

PowerVR can't do blending functions other than alpha so that's something. The PowerVR SDK also has a simple tutorial for drawing a triangle with their sgl.lib so that's also a good start.

I think the rarely used shadow stuff can be moved to a shader as well 😀 and the only real shader work to do is that, ordered dithering, and the 4-bit alpha value clamping since that's how PCX2 faded alphas.

Though, on that note, is it normal that the software mode to show up black with that wrapper?

Unfortunately, not. I've tried it yesterday, but it seems Hellbrender doesn't work with my current ddraw impl.
I know some other cases of black-screen, e.g. Pandemonium1 and Half Life menu screen are also black. Will check them later.

I originally thought that some Direct3D 2-6 emulation was in the works as well since the games that used it at the time made calls to ddraw.dll

DDraw and D3D(-7) goes hand in hand, that's true. 😀 I just didn't wanted to deal with D3D because I thought early D3D works properly on modern hw too, so wrapping that would have no point in practice. But maybe not that is the case.

PowerVR can't do blending functions other than alpha so that's something. The PowerVR SDK also has a simple tutorial for drawing a triangle with their sgl.lib so that's also a good start.

I think the rarely used shadow stuff can be moved to a shader as well 😀 and the only real shader work to do is that, ordered dithering, and the 4-bit alpha value clamping since that's how PCX2 faded alphas.

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

Huge thanks for the dgVoodoo 2, it really is a great wrapper.

I have had no problems using it in Windowed mode, but unfortunately Fullscreen mode presents problems for me.

Running it in fullscreen connected to my HDTV via HDMI, dgVoodoo 2 chooses to run in 1080i (Interlaced) rather than 1080p (Progressive). This is something that I guess could be solved if the application lets you define not just resolution but also desired refresh rate.

Huge thanks for the dgVoodoo 2, it really is a great wrapper.

Thanks! 😎

Running it in fullscreen connected to my HDTV via HDMI, dgVoodoo 2 chooses to run in 1080i (Interlaced) rather than 1080p (Progressive). This is something that I guess could be solved if the application lets you define not just resolution but also desired refresh rate.

Yes, you are right, DXGI allows the applications to choose between various scanline orders. It supports the followings: 'unspecified', 'progressive', 'upper field first', 'lower field first'.
I've just had a look, and dgVoodoo always uses 'unspecified' order. It will be exposed in the setup somehow, in the next version.

Dege wrote:

I originally thought that some Direct3D 2-6 emulation was in the works as well since the games that used it at the time made calls to ddraw.dll

DDraw and D3D(-7) goes hand in hand, that's true. 😀 I just didn't wanted to deal with D3D because I thought early D3D works properly on modern hw too, so wrapping that would have no point in practice. But maybe not that is the case.

Yeah, definitely not the case. Major examples include the Photex Engine games (Hellbender, Monster Truck Madness, Monster Truck Madness 2, CART Precision Racing, Fly!), Star Wars: Dark Forces 2 (A fix exists for this game, but stock gives you this: http://i.imgur.com/lhcyC.jpg), Star Wars: Shadows of the Empire (Fog is missing, runs too fast, menus corrupt, cinematics are corrupt.), I also recall having trouble with a few other games in the past as well.

I've released a patch version for 2.3.

While working on new things, I had a deeper look into some apps using DirectDraw.
Unfortunately I found that some of them use DDraw and GDI together. For exampe, DDraw is used only for setting resolution and GDI for drawing the screen, etc. That's why HalfLife or Carnivores demo menuscreen are black.

As for Hellbender, it uses 8bit paletted mode but the palette itself is not set through DDraw but GDI. I applied a modification for such cases but then the palette gets miscolored as with real DDraw. It is a Window7 bug AFAIK.

So, to have it perfectly working, wrapping parts of GDI would also be needed. 🙁

Yeah, definitely not the case. Major examples include the Photex Engine games (Hellbender, Monster Truck Madness, Monster Truck Madness 2, CART Precision Racing, Fly!), Star Wars: Dark Forces 2 (A fix exists for this game, but stock gives you this: http://i.imgur.com/lhcyC.jpg), Star Wars: Shadows of the Empire (Fog is missing, runs too fast, menus corrupt, cinematics are corrupt.), I also recall having trouble with a few other games in the past as well.

Then some D3D implementation is needed here... 😁

Windows 8 has that palette corruption bug fixed. I noticed that when Star Wars Rebellion worked fine.

Hey have you looked into Turok 2's Glide problem more? Just out of curiosity.

swaaye wrote:

Hey have you looked into Turok 2's Glide problem more? Just out of curiosity.

Umm, no..
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. 😀