11 August 2008, 18:25 in

OpenGL vs Direct3D

This old article, by Paul Hsieh from 1997, describes some of the significant historical events that occurred in the early days of the OpenGL and Direct3D graphics APIs.

The following is from a 1996 entry in John Carmack’s .plan file:

The overriding reason why GL is so much better than D3D has to do with ease of use. GL is easy to use and fun to experiment with. D3D is not (ahem). You can make sample GL programs with a single page of code. I think D3D has managed to make the worst possible interface choice at every oportunity. COM. Expandable structs passed to functions. Execute buffers. Some of these choices were made so that the API would be able to gracefully expand in the future, but who cares about having an API that can grow if you have forced it to be painful to use now and forever after? Many things that are a single line of GL code require half a page of D3D code to allocate a structure, set a size, fill something in, call a COM routine, then extract the result.

The world of computer hardware and software has changed a lot since then, but the information is interesting nonetheless.

Also see this comparison between OpenGL 1.2 core and Direct3D 8, and the Wikipedia entry on Direct3D vs OpenGL.

Comments

17 October 2005, 00:26 in

October 2005 DirectX SDK

I meant to post this a while ago, but here goes anyway… Microsoft has released the latest October 2005 DirectX SDK. It is available for download from the MSDN DirectX Developer Centre.

According to the description, new features include XInput, an API that allows applications to receive input from the Xbox 360 controller for Windows, and XACT (beta), an audio design tool and associated API, and it is the first DirectX SDK with features designed to take advantage of the 2.0 Common Language Runtime in Managed DirectX.

I’ve been playing around with Managed DirectX. I noticed that there is now only a single DLL that needs to be referenced which includes the various APIs such as DirectX, DirectInput, DirectSound, etc (previously each had its own DLL). I also found that several interface changes have been made to the API. For example, some method names and property names have changed, some class structures slightly readjusted, and so on. Result: a large number of compiler errors in my Pong project. :(