In one word (okay, acronym): COM.

In a couple more, DirectX uses the Microsoft Component Object Model which uses the concept of querying interfaces to determine their capabilities (not the capabilities of the functionality represented by the interface; the caps of the interface itself). This is to allow any COM-compliant application to safely determine if the necessary interface functionality is in place and gracefully terminate if not.

I''ll add this: You don''t have to keep the interface pointer fact in mind or manage them if you use Microsofts ATL CComPtr class. It''s a template class that manages the lifetime of a COM interface including internal reference counting, and it can be found in the <atlbase.h> header file (part of the Platform SDK, available for download at MSDN). Here''s how it''s used:

CComPtr< IDirect3D8 >       D3DObject = NULL;CComPtr< IDirect3DDevice8 > DevicePtr = NULL;...// this is the only time you need to call Attach with DX interfaces:D3DObject.Attach( Direct3D8Create( ... ) );/** do object validation here **/ D3DObject->CreateDevice( ..., &DevicePtr, ... ); 

Never call Release again!

furthermore, because dx is designed using com instead of the flat function model of opengl, it is completly backwards compatible and changes to implementations wont affect apps using the older interfaces. also it would be impossible to link to static objects due to the use of virtual calls.

opengl on the other hand is extended through accessing function ptrs which represetn the different extensions a driver may implement. because of this you have to check caps and check for the functions. easier for venders to add fetaures for better hardware support, but makes creating a standard interface for newer features difficult. on the flip side d3d does not allow such vendor extensions so new hardware features cant be supported until a new release of d3d. this helps control hardware venders and ensure igher compatiblity. the down side of course is that new hardware will not be able to make its new features availible for use until ms and other hardware venders agree on a standard and a new d3d is released.

personally i perfer com style api, but feel opengl is one step ahead with new feature support of hardware. however d3d has better easier ability to for ensure compatiblity between hardware when using new fetaures since the venders must follow the spec.

remeber this is not meant to be a flame war so please dont start one. i am not saying dx nor opengl are better, they both have weaknesses and strengths. though for the most part they are equal.

i like the com style at a technical level. i swear the biggest turn off for me and directx is little old lettering. the CAPS NUMBER CAP thing eww. i mean you get to be flexible as a coder but CAPS NUMBER CAP _on everything_ starts to slow you down pretty fast. there had to be a more "ergonomic" naming scheme.

i guess to the pro''s its 20 bucks a routine when you start adding it up so whats a few more minutes typing. but to a hobbyist. cringe. CAPS NUMBER CAPS WORD NUMBER. ewww

quote:Original post by declspec
i swear the biggest turn off for me and directx is little old lettering. the CAPS NUMBER CAP thing eww.

Those are typdefs. Rather than using "LPDIRECT3DDEVICE8", you can type "IDirect3DDevice8 *" - which, IMO, is more readable.

If you use a pointer, your object lifetime is controlled by you, so you can destroy objects if you''re running short on memory. I''d never go as far as dynamically allocating a game engine object, but I would dynamically allocate a graphics engine object - especially if the graphics engine needs to support several rendering interfaces/APIs:

// psuedo-code GraphicsEngine * pGfxEngine = NULL;switch( GetUserSelection( GfxAPI ) ){case OpenGL:  pGfxEngine = new OGLEngine;  break; case DirectXGraphics:  pGfxEngine = new DXEngine;  break; case v3Dfx_Glide:  pGfxEngine = new GlideEngine;  break;// etc} 

This way takes advantage of inheritance and polymorphism to provide modular flexibility to the engine architecture.