I was looking at the Allegro 5 documentation and I came across the section on deferred drawing.

This is a very useful optimization. By keeping to a single "texture", it allows you to minimize the number of state changes the renderer does. However, there are 2 ways to improve this.

The first way is to expose array textures to the user in some way. For those not knowing, an array texture is really just a 3D texture, except that filtering between depths in the texture is not allowed. This means that you can have a number of individual 2D textures that you don't need to change texture state for. This increases the gain from deferred textures. Indeed, you may only ever have one or two actual "textures", and just pull from a couple of array textures.

I'm not sure how to do this from an API standpoint. Perhaps some kind of ALLEGRO_LAYERED_BITMAP, which itself is not an ALLEGRO_BITMAP. But the user can request a layer from it, which [i]is[/i] an ALLEGRO_BITMAP. There would of course be appropriate construction and destruction functions. All of the usual operations would work as expected on the ALLEGRO_BITMAP members. All of these ALLEGRO_BITMAPs would be considered to have the same parent, and thus be eligible for deferred drawing.

The other optimization is to make deferred rendering the default. The main issue with it presently is that it isn't automatic. There is no reason why the Allegro graphics driver cannot detect when the user has changed some state and then send the previously accumulated rendering commands.

Of course, like any good optimization, this would significantly complicate the Allegro graphics drivers. But it would be to the benefit of the user. First, because the optimization would be invisible: you don't have to use special API calls to get them. Second, because the optimization could be improved beyond what the API calls require.

For example, a recent thread on this issue has relaxed the state changing requirement, allowing the blend color to be changed. Well, this requires modifying applications to use, as before this improvement, changing any of the blending state resulted in undefined behavior. If deferred rendering were more automatic, then there would be no need for such modifications; the application would simply get faster.

Deferred rendering is an optimization. Gaining access to it should require as little API work as possible.

I'm obviously not an Allegro 5 engineer. So I am not aware of what the internal issues are with regard to making deferred rendering automatic. But I do think it would be worth the effort.

The state getting issue is a non-issue, so long as you make the assumption that the user is using Allegro calls for their rendering. Thus Allegro is aware whenever state changes.

Are there a lot of cases where users are changing OpenGL state behind Allegro's back and expecting Allegro to work in some way? I do not think this is a good way to do things. If a user is relying on Allegro rendering things in a certain way, and changing OpenGL state to change how this happens predictably, then internal changes to Allegro's rendering would dramatically affect this.

For example, let's say that Allegro's OpenGL renderer currently draws using the OpenGL fixed-function pipeline. A user can bind an OpenGL fragment program to override this pipeline. However, if Allegro's internals change to instead use a fragment program itself to do certain rendering, then the user's program will be overridden by Allegro's program.

I do not think it is a good idea to encourage or rely upon this usage pattern. If this usage pattern is needed, to allow Allegro to do some things and normal GL/D3D rendering to do others, then there should be an API call. Something like "al_fix_allegro_state." This would tell the driver that the user has poked at the underlying GL/D3D state, and that it should now reassert its own internal copies of that state.

I don't think allowing the user to modify state behind Allegro's back and expecting everything to work just fine is a good idea.

The "combined bitmaps" API sounds much simpler and more effective than the one I was thinking of. One problem with this is that you can't do it at load-time. You have to do it at runtime, and after you have created your BITMAPs. Perhaps a better way would be to create a "bitmap allocator" object. You just ask it for ALLEGRO_BITMAPs, and it will ensure that they all come from the same parent, allocating chunks from the bitmap as needed. If it runs out, it can return NULL, allowing you to know when you ran out of texture.

You could make this assumption if you required the user to call some function before beginning to use OpenGL/D3D calls and another when they are done.

This would be useful information. However, we don't want to tie the API to the implementation. The current situation is not much good either. I think it would be safer to introduce explicit begin/end functions.

Not quite. The speedup of the deferred rendering is that it allows you to send a lot of vertices in a single batch, instead of having to send 4/6 at a single time. The state changes were already basically minimized before the deferred rendering was implemented.

I was planning on supporting this via texture atlasing. It's still not implemented, but it is up there on my list of things to do. The propsed API was this:

I was planning on always having a clamped 1 pixel border for the images. Space efficiency aside, would that ever be unsatisfactory?

Atlasing is more complicated than that: How do you deal with mipmaps (if you use them)? How do you deal with aniso, which with 16x AF can sample up to 17 texels away from the edge of an image?

We don't. A4.9 does not support mipmaps to my knowledge, and anisotropic mapping is only of use for 3D stuff, which is not the domain of A4.9.

Isn't that just subbitmaps?

@SiegeLord:
Well, I'd love to see the atlasing feature!

Just curious... What does "size" mean here?

Do you want to pack the single bitmaps efficiently? How?
How does the user know which size to pick for all his bitmaps to fit?

Hmm... Either don't support that case or add some function to refresh the extended border for the individual bitmap...?
I'd say if someone cares so much about performance that he puts his bitmaps into an atlas, he probably won't edit much of them anyway...