DirectDraw is still working, for the most part.

You can find the API documentation here:
https://learn.microsoft.com/en-us/windows/win … pi/_directdraw/

Azarien wrote on 2023-12-29, 22:50:

DirectDraw is still working, for the most part.

You can find the API documentation here:
https://learn.microsoft.com/en-us/windows/win … pi/_directdraw/

The API still works but the implementation of it and how much of it is supported in modern drivers is now entirely up to AMD, Nvidia and Intel. From what I have read on Dev forums AMD currently has the most complete implementation with Intel and nVidia both having compatibility issues with pre Direct Draw 7 games.

Intel has arguably the worst but that is also the same for D3D9 games too., pretty sure legacy compatibility was an after thought for Intel.

There are also wrappers for DDraw, like DXGL.
Personally, what I liked about DDraw was its bilinear filtering. D3D had worse 2D image quality, since filtering was disabled by default.

What was also nice about Direct Draw was its forward compatibility.
A Win95 era application would still function the same on Windows XP.

So 2D applications could stick with using Direct Draw and i386/i486 instructions all the time, if they were modest.

That's something that's no longer a thing, I suppose.
Back in the day, you used the lowest common denominator for a certain task, if performance/optimization wasn't necessary.

That's why 16-Bit applications were still being around for so long.
They did their job and ran on the widest variety of hardware/software platforms.

That's why new DOS or GW-BASIC/QBasic applications were still being written in the 2000s, for example.
If it was, say, an electronic database or a math solving application, DOS was still an option.

It would run on a Pentium IV w/ 512MB of RAM under Windows 98 or XP, as well as on an ridiculously outdated PC like a Sanyo MBC-555 with DOS 2.11 and 128KB of RAM.

Jo22 wrote on 2023-12-31, 00:12:

There are also wrappers for DDraw, like DXGL. Personally, what I liked about DDraw was its bilinear filtering. D3D had worse 2D […]
Show full quote

There are also wrappers for DDraw, like DXGL.
Personally, what I liked about DDraw was its bilinear filtering. D3D had worse 2D image quality, since filtering was disabled by default.

What was also nice about Direct Draw was its forward compatibility.
A Win95 era application would still function the same on Windows XP.

So 2D applications could stick with using Direct Draw and i386/i486 instructions all the time, if they were modest.

That's something that's no longer a thing, I suppose.
Back in the day, you used the lowest common denominator for a certain task, if performance/optimization wasn't necessary.

That's why 16-Bit applications were still being around for so long.
They did their job and ran on the widest variety of hardware/software platforms.

That's why new DOS or GW-BASIC/QBasic applications were still being written in the 2000s, for example.
If it was, say, an electronic database or a math solving application, DOS was still an option.

It would run on a Pentium IV w/ 512MB of RAM under Windows 98 or XP, as well as on an ridiculously outdated PC like a Sanyo MBC-555 with DOS 2.11 and 128KB of RAM.

I'm willing to bet a wrapper will give a much more accurate implementation for legacy DDRaw than any of the modern GPU drivers can.

Jo22 wrote on 2023-12-31, 00:12:

Personally, what I liked about DDraw was its bilinear filtering. D3D had worse 2D image quality, since filtering was disabled by default.

Err, I think you got things mixed up. DDraw (even 7) was very basic and IIRC never saw HW-supported alpha blending nor filtering during scaling and rotation for sprites. Games had to do that on the CPU and update the DDraw surface pixels manually.

D3D on the other hand had all those effects easily achievable via the HW texture filtering units. So sprites rotated/scaled and drawn through D3D can look smooth and nice, instead of blocky and aliasing.

wbahnassi wrote on 2023-12-31, 01:58:

Jo22 wrote on 2023-12-31, 00:12:

Personally, what I liked about DDraw was its bilinear filtering. D3D had worse 2D image quality, since filtering was disabled by default.

Err, I think you got things mixed up. DDraw (even 7) was very basic and IIRC never saw HW-supported alpha blending nor filtering during scaling and rotation for sprites. Games had to do that on the CPU and update the DDraw surface pixels manually.

No no, I do mean Direct Draw. If you selected Direct Draw in applications which were using some sort of overlay, some applications that drew their own GUI, there was bilinear filtering available.

Like for example, old DOSBox, which uses SDL1.x. Or some freeware games. Or ZSNES, I believe.

Either because of the video card drivers or some default settings. 🤷‍♂️

That no longer worked past Windows XP, though.
Beginning with Vista (+WDDM drivers), the framebuffer access was nolonger available to Direct Draw directly, as far as I know.

If you're using Direct Draw on that platform, or a later one, it looks as ugly and pixelated as Direct 3D does. Because, it really is Direct 3D that emulates Direct Draw now.

Edit: Just checked. The DDraw filtering seems to be related to stretching/scaling.
If a DDraw window is being zoomed by 2x, for example.

Ah, those so-called "DirectDraw Surface" outputs. I think they refer to a special type of DDraw surface that is typically used for video playback, and may have HW scaling support when certain conditions are met.

Those were intended for use by video players to allow nice scaling of video content to the desktop resolution, but I don't think any DDraw games used them as they were quite constrained.

Also the 'acceleration' of those surfaces were inconsistent and questionable. S3 chipsets (including Savages!) performed terribly with them and wasn't even a perfect bilinear. I don't think any commercially released game used it

Azarien wrote on 2023-12-29, 22:50:

DirectDraw is still working, for the most part.

You can find the API documentation here:
https://learn.microsoft.com/en-us/windows/win … pi/_directdraw/

I know. I am more concerned with how it is designed now

Trashbytes wrote on 2023-12-30, 23:25:

Azarien wrote on 2023-12-29, 22:50:

DirectDraw is still working, for the most part.

You can find the API documentation here:
https://learn.microsoft.com/en-us/windows/win … pi/_directdraw/

The API still works but the implementation of it and how much of it is supported in modern drivers is now entirely up to AMD, Nvidia and Intel. From what I have read on Dev forums AMD currently has the most complete implementation with Intel and nVidia both having compatibility issues with pre Direct Draw 7 games.

Intel has arguably the worst but that is also the same for D3D9 games too., pretty sure legacy compatibility was an after thought for Intel.

Do you have a source? I found them bad in one way or the other, but if AMD is being backed up I would want to see the parameters they considered

I can't speak about AMD, but their APUs are insanely popular amongst the "old games" enthusiast crowd that buys the AMD-powered mini-PCs, so it would make sense for them to put some work into their drivers, for that demographic. Intel has put in work for DX9 games via their xE/Arc GPU drivers, though I don't have a system to test, so I can't speak as to the current status of that.

RetroGamer4Ever wrote on 2023-12-31, 16:13:

I can't speak about AMD, but their APUs are insanely popular amongst the "old games" enthusiast crowd that buys the AMD-powered mini-PCs, so it would make sense for them to put some work into their drivers, for that demographic. Intel has put in work for DX9 games via their xE/Arc GPU drivers, though I don't have a system to test, so I can't speak as to the current status of that.

From an user @lowenz here on Vogons I got to know Intel added D3D8 support just in their last driver. So I guess D3D9 is acceptably complete?

But it isn't just D3D9, AMD and Nvidia works fine with older APIs as well, unlike Intel

.. another advantage of Direct Draw maybe is that it is being supported by HX DOS Extender and OS/2 Warp 4+ODIN (uses DIVE).

Win32 programs without bloat may run acceptable on those non-Windows platforms.