This project is a 3d renderer from scratch in C++. As of this commit, the framebuffer backend can be supplied by drm (libdrm). It should be run from a tty console. It can be run safely (I think) from a window manager, but no promises. It should display on the first connected port of the first video card on the fist available mode (which should be the preferred mode, I believe). 

sdl is still an option, though.

there are two final make targets: drm and sdl, which are self explanatory. drm should be run in a tty, sdl from a window manager

NOTE! in the sdl version, the terminal running the program needs to be focused to accept input (including '/' to quit)

Usage is:
./all path/to/model.obj path/to/texture.tga [/dev/dri/cardN]
where the dri card is optional. 

As it is a tty application now, the camera controls are keyboard only. See doInput in main.cc. 

The application is now multithreaded, with the number of worker threads (not the main thread) controlled by a definition in main.cc. See tpool.cc for how that works.
(it separates at the polygon level)

util.hh is object and vector class declarations

matrix.hh is a matrix class to get matrix inverses for texturing

timage.hh is a color abstraction class and an image class, largely for making a framebuffer out of a tga texture (run length encoding is not supported for tga image as of yet)

projection.hh is declarations of screen class and projection functions

fb.hh is declarations of the rendering stuff I need to write to the framebuffer.  

tpool.hh is my implementation of a thread pool object, where there can be a number of worker threads that pull any [ void function(void) ] from a queue that can be added to by any other thread.
  I *think* I covered any data races, but it is up to the user to ensure that the things in the queue are safe to execute in any order. You can effectively pass non void/void functions by capturing arguments in a lambda. Careful of copy/reference passing conventions. 

main.cc is the starting point