Ok guys, here's the deal. I am one of those old DOS programmers who has finally been forced to quit screaming, "DOS til I die!" and move on to Windows programming. Being a DOS programmer, I am curious about how the stuff works under the hood. I loved doing all of the low-level graphics in DOS. It was raw, powerful, and fast. Windows graphics (particularly GDI, yuck!) are a pain. Here's what I want to know... We all know that DirectX is just about the best thing going when it comes to games and unless you are John Romero or Michael Abrash (makers of Quake for those of you who didn't know) then DX is probably your best bet. However, like I said, I'm a DOS guy. I'm curious. Obviously, good graphics can be done in Windows, but just like in DOS, the standard graphics stuff sucks and you have to write your own (or have Microsoft write them for you So DirectX should show everyone that good graphics are possible in Windows. So my curious self asks, how does it all work? If there are any other hardcores out there that want to know how good graphics are done in Windows, or maybe if you have some answers to how good Windows graphics are done in ,I would absolutely love to hear from you all. -Russell Edited by - rtr1129 on 1/27/00 9:58:50 PM

I feel the same, I love to dig right down and program the hardware itself for faster than fast programs. Which windows prevents you from doing...

The true magic of DirectX is that its hardware independant, you don''t have to worry what hardware a system has.
Now hardware manufacturers make directx compatible drivers, so gone is the day of writting your own drivers for every potential type of hardware you expect to find and would need to rely on.
This is what happens under the hood And personaly I am grateful that its not my job to make sure I''m compatible with everything out there.

First, get Inside DirectX. This book will probably do a better job of explaining things than I can here.

Basically, the whole thing works using abstraction layers. DDraw exposes a complete set of operations to you, and when you use on of these operations, it checks whether the hardware can do it. If it can, it just goes through the driver. If it can''t, it tries to emulate the operation in software.

Everything fits together like this.

DDaw Interface
...
HAL <--> HEL
...
Hardware Driver

HAL is Hardware Abstraction Layer
HEL is Hardware Emulation Layer

Now you can query DDraw for what the hardware can and can''t do. This way, you can avoid costly emulation operations. Also, all of these operations are rather low level. DDaw isn''t a graphics package, just a way of doing hardware level operations.