AliceGL is a small, simple library designed for GPU-independent 3D graphics, and some other extras on top because why not.
Taking only minor inspiration by existing graphics APIs, AliceGL aims to be dead simple to use.
It is entirely stateless and focuses only on processing triangles and pushing pixels around. Pretty much the bare minimum for graphics.
The library is Free Software, released under the GNU LGPLv3. Its development can be followed on my GitHub.
Currently, the RasterTest project is where most of the work is being done, there I am learning the ins and outs of rasterization. Once I've done sufficient work with it, I'll put all that knowledge to use in AliceGL itself.
AliceGL is divided in 7 sections, like colours in the rainbow, dedicated to specific tasks:
The various functions of these are explained below.
This subsystem is dedicated entirely to handling buffers and textures. There are various functions available for primitive drawing of points, lines and rectangles, along with more advanced functions for drawing from textures and even fonts, along with direct pixel shading support.
Buffers are the big thing in this section. A buffer is composed of three textures (colour, depth, stencil) and various parameters concerning them. To display a buffer all you have to do is bind one of its textures to the screen surface with whatever API you want (it's fairly simple in SDL, for example).
Another major selling point is direct pixel shading. On conventional graphics APIs you'd normally have to render to texture and then draw that texture to the screen in a quad with a fragment shader for filtering. This annoying procedure is completely removed here. AliceGL lets you simply filter the contents of the buffer directly. All the heavy lifting of making a spare texture and then swapping them after the shading pass is done automatically, by the way.
The big beast, the very heart of AliceGL. This section manages the processing of triangles and their eventual drawing into a buffer. Here, the library tends to spend most of its CPU cycles.
The library works with a fairly simple data format. Each mesh to be drawn is just a bunch of arrays of vertices, normals, uv coords and whatnot, and a set of triangles pointing to these. The format makes it easy to have multi-material models (per-triangle).
Meshes can be drawn with just simple shading, but you can also provide your own vertex and fragment programs through function pointers. Everything is completely transparent so you can pretty much do whatever you want in them.
The math engine is a small but essential part that most of the other subsystems depend on. It contains functions for working with vectors and matrices, implementing both simple operations such as addition, multiplication and the like, and also more complex ones like generation of rotation and frustum matrices.
The engine also contains some functions for working with colour data types.
Collision detection between various primitives, hitscans, and more. Functions available for both 3D and 2D environments. I don't know how to implement all this but I'll learn.
A rather naïve pathfinding system based around interconnected nodes. Not much to say about it, really. I haven't done much about it yet either.
The eXtended WAD format (XWAD) is a 64-bit expansion of the original WAD format devised by id software for Doom. Apart from the obvious change of using 64-bit data types for larger archive capacity, there's support for LZ4 compression, encryption (user-handled) and symlinking, among other things.
XWADs are, of course, not backwards nor forwards compatible with old WADs, but there are conversion methods available. A WAD can easily be converted to XWAD, but note that not all XWADs can be reverted back, especially those that use large sizes and some of the more exotic features.
The Data subsystem is dedicated to interpreting various file formats for models and textures. There are planned importers for:
... And additionally, the following native AliceOS data formats:
Here are some of my projects that will be using AliceGL: