This is a bug, but I don't quite know how to fix it.

Nowadays, with GPUs being as they are, you will probably use a virtual resolution (e.g. of 640x480) and let the GPU upscale that for you to whatever resolution the desktop of the user has. This is called "resolution independence". So it's less critical to use ALLEGRO_FULLSCREEN, and ALLEGRO_FULLSCREEN_WINDOW can be used perfectly if you achieve resolution independence.

See https://wiki.allegro.cc/index.php?title=Achieving_Resolution_Independence for a bit more info on how to do this.

In Allegro 5, skip the buffer and just use transformations.

One word of caution, the ALLEGRO_FULLSCREEN driver isn't great, but i don't think it's entirely allegro's fault. I've tried (and others have tried) to make it work identically in all circumstances with all window managers, but it seems it is impossible.

In particular, any WM based on Compiz is just going to be broken, and not work right in general. I think metacity had issues when I last checked, but I can't remember for sure.

These days with everyone using LCDs, you really don't have more than one available resolution anyhow, so you're better off with ALLEGRO_FULLSCREEN_WINDOW and a transform.

I spend far too much time on the internet. (I also helped write the X port...)

The way to get good at programming is by programming a lot, andt he by to get good at using allegro is by using allegro a lot. That's all, really.

Thanks to all. Now I see that it's the best way for me - use ALLEGRO_FULLSCREEN_WINDOW and transformations. I just need to find proper scale value with lover resolutions and it's fullscreen . I still wonder how this will look when I transform my program from 320x240,640x480 or 800x600 to 1024x768 or even higher resolutions, if I dont lost "pixel clean" feeling.Worst sitiuation will be with widescreen monitors and their resolutions like 1280x800.In this case I can get scale value 1.66666.... and this must be distorted. I need to do more tests and see the results. Anyhow thanks again.

Ah, letterboxing... I suppose adding an al_translate_transform() would take care of that.

On a somewhat different note, I can't help but wonder whether this...

al_transform_identity
al_transform_build
al_transform_translate
al_transform_rotate

... is preferable to current names...

al_identity_transform
al_build_transform
al_translate_transform
al_rotate_transform

... as the former is more uniform. Uniformity helps, for example, when autocompleting functions, as the user would only have to remember "al_transform_" (realistically speaking, "al_tr" would probably be enough).

Does the unstable branch allow such changes?

Yes, it's al_verb_noun. It may sometimes be a bit harder to do autocompletion, but it reads more like English, and it is consistent. A combination al_noun_verb tends to be less legible when when you have more than just noun and verb.

For example al_get_haptic_from_joystick reads smoothly as "Get haptic from joystick" while something like al_haptic_get_from_joystick leads to "Haptic get from joystick" which is ungrammatical English.

Personally I like the Allegro naming convention it is a distinguishing feature of the Allegro API.

But I wouldn't be against someone writing a header file with alias macros, but with the clear distinction that these are not part of the official api and are for convenience only. And that header file would need to be written according to consistent rules so it's clear how long function names like al_get_haptic_from_joystick will be mapped.