I have been using Allegro to complement my direct use of OpenGL.

I think that the OpenGL frustum is set to the window size in Allegro by default (ie. 800x600 for an 800x600 pixeled window). My setup is not like that, even for 2D games.

My previous experience with OpenGL and fonts is to use the display lists which render 2D sprites and then shift the modelview matrix a bit (glTranslatef) to the right after each glyph to render the next glyph. This allowed me to render to other framebuffers and it also allowed me to use the matrix transformation functions (glTranslatef, glScalef, etc.) to position the text along with the 3D objects and 2D sprites.

Also, when loading a font, the projection matrix is altered upon the first use for caching. This can be fixed by resetting the projection matrix afterwards but this may be a bit of a problem if I intend to load fonts on the go.

However, even after this, the font is enormous when rendered. I think that its rendering function assumes that the frustum is going to be the original size (800x600 or so) rather than what it really is. Using glScalef doesn't change it.

I would like to know how other people use the allegro_font library in their programs when they do not use the typical Allegro rendering functionality. I don't really want to load fonts myself via libfreetype if Allegro can do it for me.

It's only a default, you can change it to whatever you like.

This could be a bug.

No. The font simply has the size it was loaded with. So if you load a 20-pixel font it will have a size of 20 units. If your whole screen is only 1 unit wide it is huge now. Simply scale it before drawing.

The OpenGL matrix is ignored by Allegro - you have to use transformations.

The transformations use the opposite order of OpenGL unfortunately so will be quite confusing for someone used to OpenGL. Basically something like this:

[EDIT:]

Actually, with OpenGL ES 1.0 and OpenGL <= 2.0 there also is a projection matrix applied after the modelview matrix by OpenGL. Only the latter is affected by Allegro's transformations. The projection matrix instead is set to an orthographic projection. So any perspective transform in the modelview matrix will be killed by that projection matrix.

I think we will want a way to also set the projection matrix. For ES 2.0 and GL 3 and 4 it would just be a second matrix provided to the vertex shader. So basically Allegro would have a "current transform" as well as a "current perspective transform".

The latter would just be ignored for software rendering but passed along to shaders as well as fixed-pipeline OpenGL and DirectX (I assume that also can use two matrices in the non-shader case).

Alternatively, maybe we could make Allegro not alter the perspective matrix at all. Then with non-shader GL/DX you could do your own transformations in that matrix. (With shaders you can do what you want anyway.)

But, definitely looks to me like some modification to Allegro is required if we want 3D transformations and/or a way for its drawing functions to work together better with direct GL/DX use.

You know, complaining repeatedly about the same thing for months after the bug report has been submitted (which you don't reference in your post) is not going to get this fixed any quicker .

Ah, yes, this is a known bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=3484535&group_id=5665&atid=105665

Archon, could you try this patch (made relative to the git tip). It's a workabout that doesn't fix the fundamental issue described in the bug report, but it might fix your specific symptom of it.

Obviously, you need to use al_set_projection_transform to set your custom frustrum projection for this patch to work.

I haven't been complaining about it for months... I complained about it months ago.

What about using allegro_font to paste the glyphs onto an allegro_image or OpenGL texture and extracting the glyph info for each font to compile the display lists?
I do not wish to intermingle Allegro drawing routines with OpenGL rendering routines except (as a last resort) at the init stage.

I'll have to try this on the weekend and post back on this thread. Thanks.