They are two different things.
DirectDraw and Direct3D are APIs. More specifically, they are hardware abstraction layers (HALs).
DirectDraw abstracts a simple 2D-oriented video card. Direct3D originally started life as an extension to DirectDraw for video cards that had 3D acceleration features (that means, if you wanted to use Direct3D, you first had to set up a DirectDraw environment, and then query your DirectDraw surface for Direct3D capabilities. So when you were using Direct3D, you were always using DirectDraw as well).
With DirectX 8, DirectDraw was no longer updated, and instead Direct3D became a standalone API.

Software rendering is the process of rendering a screen entirely 'in software', as in: with the CPU.
With a modern OS, you'll need some kind of API to access your display hardware for any kind of rendering, including software rendering.
Traditionally, under Windows you would use DirectDraw for both software rendering and Direct3D (in fact, Direct3D itself also offers software rendering).
However, as mentioned, Direct3D became a standalone API with DirectX 8, so you could write your own software renderer with Direct3D 8 or newer, instead of DirectDraw, if you wanted to.

Jo22 wrote on 2023-11-14, 09:50:

That's cool! I didn't know this was possible so early!

It's a trick known as environment mapping, or reflection mapping.
You take a fixed image with a certain projection so that it can encode the environment (your 'environment map'), and by properly calculating the texture coordinates, you can project this environment map as a reflection, or as a lightmap, onto your images.
It's been done in demos since the mid-90s at least, on both DOS and accelerated Amiga machines, such as this demo from 1995: https://www.youtube.com/watch?v=HtXxM0pezAs
They would often use it to fake 'phong' lighting.
The original idea was developed by Jim Blinn in the 70s: https://www.pauldebevec.com/ReflectionMapping/
The result can look very close to per-pixel lighting or even raytracing.
In fact, the famous liquid metal T-1000 robot in the Terminator 2 movie is also environment-mapped, not raytraced, as many people seem to think.

I knew that "dope" demo...it is GUS exclusive and it's also lowres 320x240/200 and yes it has some cool effects but the fukkin-demo looks way better and is one of the
first ddraw-intros that got the look of pixelshader-stuff...the reflection on the liquid surface is the key here.

dr.zeissler wrote on 2023-11-14, 17:11:

I knew that "dope" demo...it is GUS exclusive and it's also lowres 320x240/200 and yes it has some cool effects but the fukkin-demo looks way better and is one of the
first ddraw-intros that got the look of pixelshader-stuff...the reflection on the liquid surface is the key here.

The Funkkin-demo uses the same technique (environment-mapped bumpmapping), and is also lowres.

embm was bitboys and sold to matrox and they implemenred that in hardware of g400 cards and upwards, right? r7000 had that in hardware too.

As I showed with the earlier link, EMBM was developed by Jim Blinn in the 1970s.

Scali wrote on 2023-11-14, 18:01:

As I showed with the earlier link, EMBM was developed by Jim Blinn in the 1970s.

overlooked that, thx scali!

dr.zeissler wrote on 2023-11-14, 18:02:

overlooked that, thx scali!

The original paper from 1978, where he calls it "Simulation of wrinkled surfaces": https://dl.acm.org/doi/10.1145/800248.507101

OP, You are lost in details.

Software rendering: your software is computing the rendering calculations on a cpu with algorithms running on the cpu. Usually doing this with your own algorithm. Or, sometimes, using an existing implementation of someone else.

Hardware accelerated rendering: the graphics card does the rendering calculations for you, and your program is calling hardware accelerated graphics API implementations to achieve this. You are typically using D3D or OpenGL to do so. There are of course implementations of the D3D and OpenGL api which can use software rendering as well, such as TitaniumGL. Nowadays, Windows 10 also has a built in software renderer for DirectX 12, if someone has no compatible graphics hardware installed).

Jo22 wrote on 2023-11-12, 22:50:

DirectDraw is interesting, because it can be used to scale and rotate things (2D stuff).
It's a bit like Mode 7 on the Super Nintendo, I think.
Not sure if it can do parallax scrolling, too, though.

Some games use DirectDraw 2D acceleration, like C&C Tiberian Sun.

I nevery understood why the did not use hardware-acceleration on tibsun, they did that on dune2k.
With the right (agp) card dune2k scrolls 100% smooth,, I never got tibsun scroll smooth, it always stutters.

What was new and very interesting was the fact that up to DX7 using D3D always means using ddraw and d3d. I don't want to open the discussion that it is always the best to install the latest dx-version for the OS because I tend to install the DX-Version the card is supported in hardware or only one version higer. there are circumstances that using the very latest dx-version causes issues.

dr.zeissler wrote on 2023-11-15, 14:51:

I nevery understood why the did not use hardware-acceleration on tibsun, they did that on dune2k.
With the right (agp) card dune2k scrolls 100% smooth,, I never got tibsun scroll smooth, it always stutters.

Tiberian Sun is hardware accelerated, but very buggy, depending on your resolution. It can work absolutely smooth in 800x600, but struggle in 640x480 on some cards.

please give an example on what machine it scrolled smooth. (CPU/GPU/RES) thx!

My Electric Boogaloo spreadsheet.

So you could say that DirectDraw is a "way" to do Software rendering (in Windows).

Hi there,

I'm sorry if my participation in this thread counts as a necro job, I wish I'd seen it sooner. I just wanted to chime in with my 2 cents from the perspective of a developer, specializing in DirectX.

It's important to disambiguate software and hardware rendering and to understand what is done in software, why and how. Hopefully I can do this with brevity and minimum confusion.

DirectDraw is, as you know, part of DirectX. The goal of DirectX is to allow the game (or application) developer to cut through all the layers of abstraction that Windows imposes and directly access the video/graphics hardware. To provide this functionality, the burden falls on the video card manufacturer to support, in their drivers, as many of the features of DirectDraw as they can. This includes but is not limited to: Blt, BltFast, Flip, Clippers, Palettes, Gamma Ramps, Color Controls and Color Keying.

Sometimes, the video card manufacturer cannot offer one or more of these features (although the first 3 will be supported on all except the oldest of video cards) in hardware but can offer them in software. The graphics card driver is still involved, but the operation will be done with the CPU and usually with system memory. Not all features missing from the hardware are provided through the HEL (hardware emulation layer). It depends on the video card manufacturer. When the HEL is required due to lack of hardware/driver support, it's usually done transparently, sometimes with an impact on performance, depending on the operation.

Today, if you look at DirectDraw on your typical NVIDIA card, it supports just enough of it in hardware for most DirectDraw games to run on Windows 11, usually with compatibility mode options. If you could play Diablo II today, you could run it using either DirectDraw 7 or Direct3D 7 and it'd run like the wind. How I do miss that damned game.

Historically speaking, if you want to build a vintage PC that runs DirectDraw games with maximum in-hardware features, find yourself a Matrox card. Matrox were and still are the undisputed kings of 2D performance and functionality.

Perhaps of lesser interest to you but worth noting is that to get Direct3D 7, you must use DirectDraw 7. The IDirect3D7 interface is obtained from the IDirectDraw7 interface using COM QueryInterface(). Direct3D 7 literally derives from DirectDraw 7.

DirectDraw 7, on contemporary hardware, is the fastest 2D API going, especially when compiled for 64-bit. It can push incredible amounts of VRAM with lightning speed. I'm talking blitting 16384x16384 32bit color surfaces (which is 1Gb of VRAM), in mere µs (microseconds). DirectDraw and Direct3D 7 are very much supported in hardware, today.

dr.zeissler wrote on 2023-11-13, 21:59:

this ddraw demo looks incredible... like pixelshader-stuff and run on low-end machines under win95! https://www.pouet.net/prod.php?which=273
one of the best lowres effects I have seen.

I checked this out. Without looking at the source code I can't be absolutely sure of what's going on, but if I had to guess, I'd say their using surface locking to directly manipulate VRAM. I say VRAM because it's frightfully slow and surface locking is better done with system RAM, especially with SIMD instructions...you can get crazy-ass performance. I don't know if this was buggy for everyone else, but it was buggy for me. Without even seeing the source, I can tell you the cause. I had to move the mouse around for the demo to keep running. This means that instead of calling PeekMessageW / GetMessage from User32.dll in their core loop and running "while there are no messages" in the Windows message queue (the proper way), it runs "when there are messages" in the queue...

Anyway, pretty impressive. Vaguely reminded me on demoscene stuff from the Commodore Amiga.

never had any trouble with that demo on any machine I have...

Name : funkkin
Platform : PC
Place : 1
Party : LTP 4
Description : win32 64kb intro. Something not to be proud of. Very badly designed ugly intro with all the old effects. Made in one week by droid&melwyn; at fuzzel`s place in germany. Using tune by xhale, and textures by visualice&nytrik.;

https://web.archive.org/web/20021126083134/ht … jobb.scene.org/

Perhaps this still works? droid@freenet.hut.fi

This time requiring some newschool computer with windows and directX3.

uses:
MXMPLAY/win by elitegroup
UPX exepacker
DirectX

The few extra bytes in this "release" version, compared to this "compo" version, are mainly just combatility stuff.. startup-dialog, different
screenmode supports, speed & loop optimisations instead of size.. and yes, a bit less packed textures too..

made by:
Xhale playing around with SOUNDs, making smallsize MUSIC out of them
Droid creating REALTIME graphics SYNCHRONIZED into the music
Visu most of the TEXTURES
Melwyn designing some TEXTlayouts, first on paper then by CODING

With this one we were mostly funkkin at fuzzel's roommates apartment in germany. Reason why we were there was that we need to crash somewhere
between evoke in germany and ltp in France.. (oh, fuzzel's roommate maybe doesn't even know that we crashed at his room, thank you very very
very very much. hmm.. Tobias Conzelmann. and thank you fuzzel too... and thanks to xxx and hellfire too.. and to netpoet.)

Armitage Shanks wrote on 2025-03-30, 14:45:

Anyway, pretty impressive. Vaguely reminded me on demoscene stuff from the Commodore Amiga.

What stuff are you thinking of exactly?