Simple, really. Some systems, notably OpenGL, just don't have masking. Rather than force them to create masking using other hardware features, we give them an easy out. We allow them to use alpha blend/test hardware to implement masked bitmaps. As such, they can also disallow the simultaneous use of blending and masking.
It is very important for the user to be able to ask for a driver that can perform some set of tasks. This allows them to be assured that the features that they want to use will operate at a reasonable speed. Allegro 4's autodetection feature lacked this, and therefore one was unable to select drivers that would provide for various features without actually enumerating them manually.
One of the primary cons of this setup is that it makes creating a graphics driver a somewhat onerous task. This is only partially true. The API could easily exist to allow for creating a driver using very few hints. This would allow simpler applications to be able to create the drivers that they need to. Also, the name of the chosen driver can be saved to a config file and used later.
Long story short, this feature helps achieve the goal of promoting the use of hardware features.
One of the principle problems when using OpenGL is not knowing whether some combination of state will provoke software modes. This problem is compounded by the fact that OpenGL state is so vast. Granted, this was much more of a problem in the past than currently but it even now remains a problem.
In our case, we have a similar problem with blitting, but the state in question is quite small. Granted, there are quite a lot of blit-params, but it is nothing compared to OpenGL state.
Also, blit-params makes sense as an organizational technique. People tends to only use a few separate blitting styles. Blit-params fits into a blitting style motif. By simply changing the blit-params on an object, one can change how it is rendered.
Once you have a blit-params struct, it is trivial to make an API that asks the driver whether it will be fast or slow. Being able to ask this question allows the user
Note that the user does not have to ask this question. He can freely ignore the API, and the blitting will still happen as it should.
This exists for the sole purpose of giving the user more information about what can and cannot operate fast. The user needs this kind of information in order to make reasonable decisions about which effects to use or to leave out.
Two reasons.
Palettes are difficult to support in hardware, especially in the absence of hardware-based support. Color conversion between RGBA formats and palettes is also a difficult thing to specify.
Equally importantly, palette-based rendering is a somewhat "backwards" feature anyway. Increasingly, hardware developers avoid supporting palettes, and if they do, these kinds of bitmaps severely restrict the operations that can be performed on them. Palettes are an idea whose time either has already passed or is currently passing.
Allegro 4's blending functions were pretty poor.
First, the concept of modulation was made a part of the trans blitter, when all logic and reason says that it has nothing to do with blending. This is done because it is easy enough in software to replace the destination color with a constant color passed in. However, most actual blending hardware does not work that way.
Second, few of Allegro 4's blending functions could be made to fit within OpenGL's blending operations.
Third, Allegro 4's blending functions were just not that terribly useful, overall. Mirroring OpenGL's blending functions seemed to be a much more reasonable way to go about this.
Without it, a developer can easily do the wrong thing and crash the game. It only costs one short (maybe even a char) per shared bitmap data. It's trivial to implement and it makes the API more robust.
It is a useful feature that takes practically no time, and will be appreciated by many developers. This is a game programming library, not a hardware abstraction library. As such, we can take a higher-level stand on various features.
The user would like to be able to specify any and all blitting operations simultaneously. There is no reason to prevent blending and rotation simply because the function for doing rotation is different from the blending function. If the hardware cannot handle it, we have a mechanism for dealing with that.
Also, having a structure that encapsulates blitting parameters is useful to the user too. Besides allowing AllegroPro to have an API for querying whether a given blit-param will function in hardware, the user can use blit-params just to keep track of how certain regions of code perform blitting operations.
Multiple monitors are multiple framebuffers. But, they are not (necessarily) multiple drivers.
Um... it's useful for showing movies? That's, pretty much, all it's good for. Movies tend to be decompressed into YUV. Adding a color space conversion from YUV to RGB is not necessary with a YUV overlay.
Personally, this is a low-priority item at best. It has no orthogonality issues, so it can be added or removed at will.
Um... it's useful if the user can't be bothered to set the gamma himself?
This is a notably dangerous feature to add, if for no other reason than the fact that gamma is a global setting. It does not belong to a window; it belongs to the entirety of the video hardware. If an application should modify this, and crash, then the player's machine has been placed in a poor state. Attempting to trap crashes to change the gamma back is an even worse solution, because it makes debugging crashes that much harder. A debugger can't get back to where the crash happened if some exception handler caught the exception.
Personally. not only is this a low-priority item, it has enough potential negative consequences to be left out entirely. Notice that the design lacks a specification for it. Also, it is not even a driver feature, since its effects are global. As such, it is a feature, like overlays, that can be added or removed as needed.
Non-generic drivers has significant limitations on the available drawing primitives. In general, hardware doesn't usually support such drawing primitives. This would force a software solution for things like circle, ellipse, and floodfill. We wish to encourage the user to not use functionality that is in software. So, we simply don't let them. They can still build a generic bitmap and use that, but it would be a bad idea to force hardware drivers to do it.
Note that this restriction can be relaxed if it turns out to be a bad idea in practice.
The purpose of providing for emulation mode is to prevent drivers from implementing it. By adding it to the AllegroPro core, driver developers don't have to worry about it. Writing an AllegroPro graphics driver is hard enough. Also, by putting this into the core, it is written in one place. Since it can work with any driver, it is just fine to have it written and debugged once.