Note: This website is archived. For up-to-date information about D projects and development, please visit

Library Outline

Application, Window and Event are essentially complete. They provide interfaces to abstraction classes and generic event handling though a publisher/subscriber mechanism. Unicode is implemented as wchar (16bit) throughout the entire library, including input.


The Microsoft Windows (2000, XP, and Vista) platform is approximately complete, spare a few extended features, namely drag and drop support. I am interfacing directly with Win32 here, and the code has not been tested with Win64, but there's no apparent reason why there would be a problem.

OpenGL support is achieved through WGL.


I use X11 directly, so this abstraction should work on many Unix platforms including Mac OS X using their own X11 implementation - however such testing has yet to take place. There's still some more event handling code to be finished, but what's there is working well.

OpenGL support is achieved through XGL.


I have yet to get a functional development environment on Leopard, so Mac OS X has not yet began. I have acquired some bindings for Carbon, but they are untested and likely incomplete.

OpenGL support will be achieved through AGL.



The Win32 binding in use is a minimalistic approach, implementing only the functions and definitions absolutely necessary to do what I need.


The XLib binding in use is a collection of several resources, and seems to be the most complete one out there. It may be donated to another project like tango in it's entirety, and then minimized to a bare minimum implementation much like the Win32 binding came to be.


There's nothing done here yet, but I do have the Carbon bindings in a spread out and messy form that will eventually make their way into this module in a clean and unified form. As soon as I get a development environment working on Leopard, this will be a top priority.



This binding is a combination of all gl* and glu* functions and definitions, up to the OpenGL 2.0+ spec. The binding is directly linked, however a mechanism is in place to dynamically link extensions. The entire OpenGL (and related modules) implementation uses anonymous enumerations to provide access to GL_* keywords, without using up memory in the compiled binary with hundreds of const int declarations.


Each of these modules provides optional access to many popular OpenGL extensions. They use a unified loading function, and are enabled or disabled by passing a version of the extension name. The loader automatically checks for support, and also warns if any functions fail to link (in debug mode).


Each of these bindings are the bridge between the host operating system and OpenGL. They are directly linked bindings like GL, but of course versions are used to automatically select the correct modules for the host platform.

Cg and CgGL

These bindings have been cleaned up and tested. So far they seem to work without a hitch, and should prove to be a very powerful method of code-optimization. One rule is that anything that is accelerated with the use of the GPU will have a CPU version as a fall back.


This package is a new piece of software that I have been working on that performs 2D graphics operations, much like ImageMagick?. It currently has the capability of rendering anti-aliased bezier shapes, loading png files, and compositing multiple maps (bitmaps) together using a pixel-shader system. The current design of the package is likely to change dramatically, to enhance performance and flexibility. The goal of this system is to provide the rendering capability of Photoshop and beyond in a near-real-time, easy-to-use manner.



As the drawing code comes together, this is an important part - the 3D model. So far nothing is very well optimized, but you can write (or convert) simple 3D models into a format that looks like CSS. There's a simple reader built into the ModelCell? struct. This is all temporary, but parts of it are signs of what is to come.



This is the managed rendering abstraction that the entire GUI system will use. A composite has any number of layers, which are essentially just textures when drawn, so ideally you only have to update most layers infrequently, whereas one layer will be updated frequently - such as the area of the GUI you are working in at the moment. Thus, each layer is cached, and redrawing the interface is extremely fast. Another bonus is the eventual use of p-buffers or frame-buffer-objects will make this design cost little or nothing in drawing time, while obviously accelerating GUI composition.


In a GUI sense, a layer would be used as a container, much like a frame. Implementation-wise, a layer is an abstraction to the concept of rendering to a texture. All you need to do is begin the layer, perform drawing, and end the layer. If the layer is attached to a composition, the composition will take care of drawing the layer in the final rendering (the one the user actually sees). Layers have a position and opacity already, but additional features will include blending modes and layer effects - identical to Photoshop's common layer properties. Beyond what even Photoshop offers - layers will also have real-time filters including blurring, and non-destructive (but still anti-aliased) scale and rotation. Finally, layers will be assembled in either 2D or 3D space, depending on how you design your app.