Vid:
Your directdraw hardware drivers must not be set up properly then, even with microsoft using the com interface, adding an extra layer of foolishness, it still should be MUCH faster than anything you can make, even using every assembly optimization mmx/sse trick. Unless you are talking about your code being faster than directdraws software code, then I would say you most likely could make it faster than anything Microsoft can produce. Also if your system is stealing system ram for video graphics then that would produce a major bottleneck also. Also, none of my examples use the directdraw hardware blitter yet, so you can't use these to make a conclusion. One more comment, you WILL need speedy software drivers to do anything special, like rotations, and scaling, unforntunately, If you want any hardware acceleration, you'll have to use direct3d (Which I've just started hammering out in this version of my library )...

so you say ddraw can't use hardware acceleration?

ddraw does simple hardware blits, FAST, but for scaling, rotation, and blending, unfortunatly, you'll have to write you own software functions.

so why does it have structures and functions for it then? some oversighted future-compatibility? :]

Microsoft dropped support for it to better focus on direct3d, and the other interfaces. So, any additional functionality that they had planned was most likely scrapped. The reason for the sturctures still being there.