[AD] held drawing and primitives

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

I know I've brought this up in the past, but I think this would be REALLY 
handy. If held drawing also worked with the primitives.

SiegeLord has said that it is possible but requires a rewrite, which is 
unfortunate.. I am willing to help with such a thing, because one of my 
projects either needs it, or has to re-implement everything from 
al_draw_bitmap, al_draw_text, to every single primitive.

Since the ttf addon doesn't seem to export its internal render methods, I'd 
essentially have to re-implement the entire addon in my own project. Which I'd 
rather not do if I don't have to.

I already started on designing the necessary infrastructure for my project to 
handle full deferred drawing:

struct PaintEngineVert {
	static const int VERT_STRIDE = 10;
	double d[VERT_STRIDE];
};

struct PaintEngineStoreRange {
	DynArray<int> idx;
	int texture;
};

struct PaintEngineStore {
	PtrArray<PaintEngineStoreRange> range;
	DynArray<PaintEngineVert> vert;
};


Though I'm not sure if its missing anything important.

Basically it stores a big blob of vertices in interleaved format (xyz+rgba+uv) 
for use with something like glDrawElemets, each drawing command will append 
three or more vertices to make up one or more triangles (using triangle 
lists), and append three or more indices to the current StoreRange structure. 
When the texture is changed, either a new StoreRange object is pushed onto the 
stack, or an existing one is selected from the stack which contains the same 
texture id, where any subsequent drawing operations are added. Also, every 
vertex's z is set to the current "Depth", that is to say, some value that 
places it behind any items that were drawn after them, so things actually look 
correct once everything is drawn. This is important, because the structure 
stores objects out of drawing order, and without it, drawing operations would 
layer wrong.

With this structure, all held drawing operations should be sorted by texture, 
and an absolute minimum of texture switching will need to be done. One 
simplification could be made to just not look for any existing StoreRange in 
the stack, and just allocate a new StoreRange when the texture is switched, 
that may also allow the code to skip dealing with the z value, but I think in 
some cases the performance improvement may be worth it, and the overhead isn't 
that large.

Do you think its worth it?

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx