Ove Kaaven wrote:
>
> I've looked at the DDK, and it seems that whoever designed DirectDraw/3D
> weren't the same guys that designed DirectSound. There isn't exactly a COM
> interface, rather the HAL interface is a range of C structures and
> callbacks (although GUIDs and vtables seem to be referenced here and
> there), e.g.
>
> typedef struct _DDHAL_DDCALLBACKS
> {
> DWORD dwSize;
> DWORD dwFlags;
> LPDDHAL_DESTROYDRIVER DestroyDriver;
> LPDDHAL_CREATESURFACE CreateSurface;
> LPDDHAL_SETCOLORKEY SetColorKey;
> LPDDHAL_SETMODE SetMode;
> LPDDHAL_WAITFORVERTICALBLANK WaitForVerticalBlank;
> LPDDHAL_CANCREATESURFACE CanCreateSurface;
> LPDDHAL_CREATEPALETTE CreatePalette;
> LPDDHAL_GETSCANLINE GetScanLine;
> // *** New fields for DX2 *** //
> LPDDHAL_SETEXCLUSIVEMODE SetExclusiveMode;
> LPDDHAL_FLIPTOGDISURFACE FlipToGDISurface;
> } DDHAL_DDCALLBACKS;
Well, the SetMode callback could be used for XVidMode/DGA support,
if we can retrieve the cooperative window from the DDraw object
it gets passed. We might also be able to do DXGrab this way as
well, but that raises the issue that in Windows, the DD driver
HAL interface above is intended for video use only, not input
use. I'm not quite sure where it's appropriate for us to make
a connection between video and input related stuff. We certainly
*could* have the x11driver ddraw HAL make the call to grab the
mouse, but I don't know if this is the cleanest way to do things.
None of the DDK interfaces that I've seen seem to lend themselves
to the task of managing our glX context needs. They have
'context' APIs, but they're on a per D3D Object level, which I don't
think meshes well with glX. Also, they don't seem expose an API to
set the context.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
[EMAIL PROTECTED]
