It's something that's inevitable, unfortunately.

You'll have to excuse me using ARBfp instead, as I'm more familiar with that end of the graphics pipeline.

Consider, for example, that the Radeon 9700 doesn't natively support trigonometric functions; instead, it must use several instructions to compute them. The Radeon 9700 also doesn't natively support all 256 possible swizzle suffixes, meaning that some instructions need to be broken down into several instructions.

Both of those will affect the final speed of the program, yet cannot be directly seen from the source code.

This isn't limited to the R300 though, as not all GPUs support all of ARBfp natively.

Secondly, limiting the instruction set, especially on a standard extension, limits the potential of effectivally using the hardware. If the GPU had a native trig unit, that unit will be idle almost all the time because the language only provides for MAD/MUL/ADD. Although the task of converting a SIN opcode into the equivalent native instructions is trivial, doing the reverse (converting a sequence of MADs with funny constants into a native SIN opcode) is not.

I just tried compiling RC3 under linux. A bogus "static typedef" stopped the compilation, but that was easily solved:

--- glext.c.old 2004-01-15 21:17:58.910277016 +0100
+++ glext.c     2004-01-15 21:18:05.264311056 +0100
@@ -78,7 +78,7 @@
 #ifdef ALLEGROGL_HAVE_DYNAMIC_LINK
 #include <dlfcn.h>

-static typedef void* (*GLXGETPROCADDRESSARBPROC) (const GLubyte*);
+typedef void* (*GLXGETPROCADDRESSARBPROC) (const GLubyte*);
 static GLXGETPROCADDRESSARBPROC aglXGetProcAddress;
 #endif

I also got the following warnings:

examp/exext.c: Dans la fonction « _mangled_main »:
examp/exext.c:170: WARNING: implicit declaration of function « strlen »
examp/exext.c:191: WARNING: control reaches end of non void function

Apart from these, everythind compiled and ran just fine!

So, I was browsing the AllegroGL source code, when I found the code that deals with masked blitting.

In hardware that doesn't have 3-way multitexture or better, you do this glDrawPixels, which stands as the slowest method to update screen pixels in OpenGL. If it is an nVidia card, you use 2 register combiners. If it is not, and it has 3-way multitexture, you use 3 tex-env combine operations, and 3 fetches from the same texture (in the same place, granted).

Why? Where is all of this coming from? Why not just upload video BITMAPs and, at the time of uploading, pick an appropriate alpha value per-pixel? I can understand doing this kind of thing for memory-to-screen, but why for video-to-screen, where you have full control over the contents of the data?

Well, it works in Allegro's software mode. Maybe I didn't explain what I mean precisely.
Take a d_list_proc for example. You can use its bar to scroll up and down through all options. However, in AllegroGL it doesn't show how you scroll. You press the scroll bar and can move it up and down, but the screen doesn't get updated until you release the mouse button.

EDIT: ok, I think I found the problem. All (at least d_list_proc and d_button_proc, I didn't check the others) have this line somewhere, which hogs the mouse until the buttons are released:

while (gui_mouse_b())
However, this loop also sends MSG_IDLE to the whole dialog, so it still works. The problem with AllegroGL is now, that allegro_gl_flip is called inside algl_do_dialog, but that line will never be reached while the mouse buttons are pressed, since it's stuck in the loop. I made a little workaround by adding a new line at the end of my dialog structure, which simply does an allegro_gl_flip when it receives MSG_IDLE and the mouse button is pressed.

<code>
int d_flip_proc(int msg, DIALOG *d, int c)
{
if(msg == MSG_IDLE && mouse_b) {
algl_draw_mouse();
allegro_gl_flip();
}

return D_O_K;
}
<code>
I guess there's nothing AllegroGL could do, as changing this behaviour would require to modify the Allegro code