Allegro 5 has software implementations of image and primitive drawing (including scaling, rotation and blending). However, doing these things on the main CPU is much slower than what a dedicated graphics card GPU can do. Therefore if the drivers are capable of it, all graphics operations are done in hardware. To this end each ALLEGRO_BITMAP for example will actually be a texture uploaded to the graphics card. And each graphics command, be it drawing a rotated blended image, or simply a line, is implemented as a command sent to the graphics card.
More accurately, what happens all depends on the "driver" Allegro is using. In most cases, this will be either Direct3D or OpenGL (as of right now, there are no other drivers). And depending on the used hardware, there are certain restrictions what can be done. For example commands to do some things might not be available at all, or if they are available, the D3D or GL driver itself might fall back to a slow software implementation. Or doing the operation simply will be slow on the used hardware. This page is to list some of the pitfalls and how you might code alternate paths in your game so users of older hardware can still enjoy your game (even though with somewhat tuned down graphics).
Non-power-of-two (NPOT) textures
Before OpenGL 2.0, the graphics cards would limit textures to power-of-two sizes. That is, 64, 128, 256 and so on. Allegro detects this and uses the next bigger texture size to create the internal texture for an ALLEGRO_BITMAP - so in most cases, you do not need to care. However if you use the textures directly, you might want to be aware of it. Check the OpenGL version of NVIDIA and AMD graphics cards.
Maximum texture size
There is a maximum texture size (like 1024x1024 or 2048x2048) for some cards. Usually you won't run into it - but if you do, Allegro will simply fail creating bitmaps of this size unless you request a memory bitmap. A good workaround is to never create (non-memory) bitmaps which are bigger than 1024x1024 as virtually all cards will supports that.
In many games, everything you draw will be drawn to the screen. This works everywhere. However, sometimes you want to drawn into another bitmap. On some old hardware, this is slow. Specifically, with OpenGL, the framebuffer-object (FBO) extension needs to be available for this to work. Otherwise Allegro will fall back to a very slow software implementation, first "downloading" the texture, then drawing into it, then "uploading" into it. If you just modify a bitmap from time to time, you don't need to care - even the slow fallback version will be ok. But if your game includes an effect which draws into bitmaps each frame, you might want to include an option to disable it.
One issue to be aware of with blending is the use of separate alpha blending - it may not be supported with older drivers. To ensure optimum performance, use for example a blending mode of:
<highlightSyntax language="c"> al_set_blender(ALLEGRO_ADD, ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA); </highlightSyntax>
<highlightSyntax language="c"> al_set_separate_blenderALLEGRO_ADD, (ALLEGRO_ALPHA, ALLEGRO_INVERSE_ALPHA, ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_ONE); </highlightSyntax>
If you render to the back buffer, or to a solid bitmap target, the effect will be the same as the target alpha channel will not be present anyway. And the first version is guaranteed to always work. In the second case Allegro might fall back to very slow software emulation if the underlying Direct3D or OpenGL driver does not support it. Also even if it is supported, it may still be slow if the hardware can't do it.
It can make things look much better as all the hard pixel edges disappear - but on some hardware it may not be available, or be much slower. You can use al_get_display_option(ALLEGRO_SAMPLE_BUFFERS) and al_get_display_option(ALLEGRO_SAMPLES) to check if your current display was created with multi-sampling enabled. But even if it is available, it's best to give users an option to turn it off as they might prefer higher FPS over prettier graphics.