I have written a small test program. This generates a red background and a blue rectangle of pixels to be drawn on top of it.

My question is: Why does the red background cover the entire Android screen although the display is set to 800:600 while the rectangle of the same size stays at that size and is not zoomed accordingly?

Further, how do I set the ALLEGRO_PIXEL_FORMAT so the colors are written on top of each other with XOR?

For iOS, no matter what you do, you get a display with the size set by the system. I think Android should probably do the same (i.e. it should have the behavior implemented for ALLEGRO_FULLSCREEN_WINDOW for every flag).

Thank you for your posts. Yes, it seems that Android always uses the full screen of the current device.

I got into a further problem. When I try to write two bitmaps to the screen using al_draw_bitmap_region() the first one is cleared to background color. Any idea why this happens and what should be done to have both bitmaps on the screen?

I have this problem in my large program too but I demonstrate it here with this demo program.My tablet has a 2560, 1600 pixel screen size.

If I have drawn the first pixel block and the user makes an input, I want to draw the second pixel block at a different location on the screen and leave the first as it is. How should I implement that then? I guess I have to make two al_flips then.

A flip always switches between multiple backbuffers, so it certainly can't work that way (with the second flip you'd always dispose the effects of the first flip). You need to make sure to draw everything you want on the screen for one frame between your calls to al_clear_to_color() and al_flip_display(), both of which should only be called once per frame (with a few exceptions for al_clear_to_color(), but let's ignore that here).

Normally, when programming a game, you have some kind of game loop, which makes implementing the kind of behavior you want easier. It's still possible to implement with your current version, but you'll have to copy the drawing of the first rectangle, which of course makes the code a bit messier. You'd want something similar to this then:

I would prefer to have one buffer in memory and partially modify that as needed after a user input and then write that modified buffer to the screen using al_draw_bitmap_region. I guess if I do not al_flip the result of al_draw_bitmap_region will not appear on the screen.

I do not want to build up the entire screen contents each time before al_flip if it can be avoided. My program is currently designed differently.

I am trying to use Allegro as a graphics backend to a library. That library passses me blocks of pixels which shall modify part of the current screen contents. If the block of raw pixels I get would be an Allegro bitmap I could just use al_draw_bitmap_region. They are just a block of 4 byte truecolor pixels.

Instead of rendering to the display directly, create a screen-sized bitmap at the start of your app, set this bitmap as your target bitmap, clear it once and then perform all your subsequent drawing operations on this one bitmap without ever clearing it again. When you do this, you only have to blit this bitmap to the display backbuffer before every call to al_flip_display(). In this case, you don't even have to clear the backbuffer each frame because you're completely overwriting the whole backbuffer contents each frame, anyways.

I'd give you some example code, but I don't have much time right now. I hope my explanation was helpful enough.

The main takeaway here is, you have to assume the contents of the backbuffer are undefined (in the programming sense of undefined behavior) after a flip. It could be garbage pixels, a render from 3 frames ago, black, etc. There's no way to tell. Best not to assume anything.