Hi all,

I'm trying to use Allegro 5.2.6 on Ubuntu 20.10
Here's a test case showing the problem I'm having.
When using a memory bitmap for a background image.
If I draw a sprite on top of it, I'm getting black boxes where I should
be seeing the background color.
It also seems to affect drawing primitives.
see attachment.

Everything works fine, if I use a video bitmap for background image.
But I wanted to use a memory bitmap because I'm going to do lots of drawing to it.

What am I doing wrong?

Thanks,
all.

It's doing what you told it to do.

1st bitmap is blue
2nd bitmap is black with line through it

It's drawing the black bitmap to the blue background.

You need to set the alpha channel to transparency for the black portion of the bitmap.

al_clear_color(temp, al_map_rg(0, 0, 0));
al_convert_mask_to_alpha(tmp, al_map_rgb(0, 0, 0));

DanielH,
Apologies, I should have attached the test.png file.
I updated my original post,

1.
you can see that test.png does have transparency for the background.

2.
And even if the test.png was broken (it's not), that does not explain the black boxes when drawing the line.

to clarify:
if I use a video bitmap for the background image there are no black regions.
It only happens when I use a memory bitmap.

Thanks.

al_clear_to_color(al_map_rgba(0,0,255,255));

Is it necessary to do that with a memory bitmap? Wouldn't:

al_clear_to_color(al_map_rgb(0,0,255));

be more suitable?

Yes and also this clear command also.

al_clear_to_color(al_map_rgb(0,0,0));
al_draw_bitmap(bg, 0, 0, 0);

To your problem, I'm not sure. I'm not at home to test it.

What happens when you remove or comment out the draw line?
Do you still get the black under sprite?

DizzyEgg:
using al_map_rgb vs al_map_rgba does not remove the black.

DanielH:
removing the al_draw_line() call still leaves the black under the sprite.

Thanks.

I cannot open your "test.png", I get an error.

Could you try the one I have attached, just for testing? (No pun intended).

DizzyEgg
tested:
as expected, test2.png made no difference.

We can safely rule out the png file.
the sprite gets loaded to a video bitmap.
it draws fine when the background image is a video bitmap.
png file is not the problem.

Thanks.

I have just tested using your original code and test.png (on Windows) and it works fine, must be a Ubuntu bug....

[EDIT]
Can you try to clear the display before drawing?

    al_set_target_backbuffer(display);
    al_clear_to_color(al_map_rgba(0,0,0,0));
    al_draw_scaled_bitmap(tmp, 0, 0, al_get_bitmap_width(tmp), al_get_bitmap_height(tmp), 0, 0, al_get_display_width(display), al_get_display_height(display), 0);
    al_flip_display();

DizzyEgg:
tried it, that made no difference.

But you bring up an interesting point. It might be an opengl bug.
Sorry I don't have windows10, but could you try and force allegro to
use opengl instead of directx and see if you can reproduce the bug on windows.
otherwise, it's looking like an allegro opengl-linux bug.

Thanks.

I have tried using both DirectX and OpenGL.

Both work fine on Windows.

This looks like an Ubuntu specific bug; sorry I cannot be more help, but I don't have Ubuntu.

[EDIT]
One last try!! Maybe this?

nope, changing the order made no difference.
Thanks.

The memory bitmap you are creating may not have an alpha channel.

Try setting the new bitmap format before creating it.

al_set_new_bitmap_format

Make sure you select a format with an alpha channel.

Edgar:
It's not drawing the sprite to the memory bitmap(bg), it's drawing to the temporary-buffer(tmp) which is a video bitmap.

I checked on Debian (which has 5.2.4 packaged) and also with current git HEAD, both were OK.
Could be Ubuntu specific I suppose.

IIUC you are saying that merely drawing a memory bitmap (bg) to a display causes it to produce artifacts when you later draw primitives onto it.

What happens if you skip the 'tmp' part and draw directly to the window's display?
Also what if you al_save_bitmap the 'tmp' bitmap, is that also corrupted?

Peter,

merely drawing a memory bitmap to a staging video bitmap, produces the artifacts for subsequent drawing of images/lines.

>What happens if you skip the 'tmp' part and draw directly to the window's display?
it works fine if I skip tmp, and draw straight to the display backbuffer.
it works fine if bg is a video bitmap.

tested: yes, the output image via al_save_bitmap also has the artifacts.

Thanks.

Looks like a driver bug, but I don't really get what the mechanism would be. When bg is drawn to tmp, tmp is locked READWRITE, and all the pixels are drawn in software. I don't have an explanation why the blocks only appear after the sprite and line are drawn. I'd be curious what the pixels in tmp look like after bg is drawn.

I'd avoid using memory bitmaps, and instead do al_lock_bitmap on bg before calling your `al_put_pixel`'s.

Siegelord:

I originally started with a video bitmap for bg and performance with al_lock_bitmap and al_get_pixel/al_put_pixel was horrible.

As a work-around:
I ended up creating another buffer just to copy bg to video-bitmap.
That way I can use all video bitmaps in the final draw.
I hate to waste memory, but my game is low-res, so no matter.

I'm good now.
I'll close the issue on github.

Thanks to everyone for the help.