allegro5
allegro5 copied to clipboard
al_draw_bitmap_region graphics glitch when dy has offset of 0.5f
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;
}
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?
To be clear, what are the dimensions of your
image.png
? Are they 48x42?
Yes, exactly.
Could this be a driver issue?
I tried on Mac:
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.
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.
And here's the screenshot of that program:
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.