allegro5 icon indicating copy to clipboard operation
allegro5 copied to clipboard

al_draw_bitmap_region graphics glitch when dy has offset of 0.5f

Open GOMF opened this issue 4 years ago • 5 comments

In Allegro v5.2.6, when I try to draw a bitmap with al_draw_bitmap_region with a dy value that has an offset of 0.5f, the image is drawn as if sy has an offset of -1. See code and screenshot below.

#include <allegro5/allegro.h>
#include <allegro5/allegro_image.h>

int main(int argc, char* argv[])
{
    al_init();
    al_init_image_addon();

    ALLEGRO_DISPLAY* display = al_create_display(256, 192);
    ALLEGRO_BITMAP* img = al_load_bitmap("image.png");

    al_draw_bitmap(img, 0.0f, 0.0f, 0); // original bitmap

    al_draw_bitmap_region(img, 24.0f, 14.0f, 24.0f, 14.0f, 170.0f, 70.5f, 0);

    al_flip_display();

    return 0;
}

al_draw_bitmap_region glitch

GOMF avatar May 02 '20 15:05 GOMF

I tried to reproduce this, but failed (on Windows with D3D and OpenGL backends). To be clear, what are the dimensions of your image.png? Are they 48x42?

SiegeLord avatar May 03 '20 05:05 SiegeLord

To be clear, what are the dimensions of your image.png? Are they 48x42?

Yes, exactly.

Could this be a driver issue?

GOMF avatar May 03 '20 11:05 GOMF

I tried on Mac: ss I also added the line

    al_draw_bitmap_region(img, 24.0f, 14.0f, 24.0f, 14.0f, 10.0f, 70.0f, 0);

As suggested, using 70.0f instead of 70.5f it looks ok. Also attached my image.png just so you can check I got it right. image

pedro-w avatar May 03 '20 12:05 pedro-w

Reproduced it on Linux. It's not obvious what can be done here. Here's some discussion about placing the texture coordinates better, but my attempts to do it haven't borne fruit. Here's a evolution of the code above to test that idea (by introducing the offt variable). The idea is that there should be a setting of offt that fixes this issue, but I haven't fully understood the way to derive it (or if its possible). Note that there's also a confounding issue that the texture might actually be NPOT, i.e. 64x64, under the hood (al_get_opengl_texture_size can be used to figure this out).

#include <allegro5/allegro.h>
#include <allegro5/allegro_image.h>
#include <allegro5/allegro_opengl.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
    al_init();
    al_init_image_addon();

    ALLEGRO_DISPLAY* display = al_create_display(1280, 1048);
    ALLEGRO_BITMAP* img = al_load_bitmap("data/image.png");

    al_draw_bitmap(img, 0.0f, 0.0f, 0); // original bitmap
    int w, h;
    al_get_opengl_texture_size(img, &w, &h);
    printf("%d %d\n", w, h);

    int N = 1000;
    
    float offt = 1. / (42 * 4);

    for (int i = 0; i < N; i++) {
        float x = 170 + 30 * (i / 30);
        float y = 30 * (i % 30);
        
        al_draw_bitmap_region(img, 24.0f, 14.0f + offt, 24.0f, 14.0f - offt, x, y + i * (1. / N), 0);
    }

    al_flip_display();

    ALLEGRO_EVENT_QUEUE* q = al_create_event_queue();
    al_register_event_source(q, al_get_display_event_source(display));
    ALLEGRO_EVENT e;
    al_wait_for_event(q, &e);

    return 0;
}

I also used a slightly modified image, to make things a little easier to see.

image

And here's the screenshot of that program:

screen

SiegeLord avatar May 03 '20 21:05 SiegeLord

A mix of two transform happen here, which make the bug in the result. From origin bitmap and display.

I still don't know how to fix it.

Also a new test is required for check if the bug persist.

rmbeer avatar Feb 25 '23 20:02 rmbeer