[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2010-08-06, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> > 2.
> > Index: src/opengl/ogl_bitmap.c
> > ===================================================================
> > --- src/opengl/ogl_bitmap.c (revision 13538)
> > +++ src/opengl/ogl_bitmap.c (working copy)
> > @@ -561,7 +561,7 @@
> > * However if we do that, without NPOT textures, we get some junk at the
> > * edges of our bitmaps when we draw them.
> > */
> > - unsigned char *buf = al_calloc(ogl_bitmap->true_h, ogl_bitmap->true_w);
> > + unsigned char *buf = al_calloc(4, ogl_bitmap->true_h * ogl_bitmap->true_w);
> > glTexImage2D(GL_TEXTURE_2D, 0, glformats[bitmap->format][0],
> > ogl_bitmap->true_w, ogl_bitmap->true_h, 0,
> > GL_ALPHA, GL_UNSIGNED_BYTE, buf);
> >
> > I have hardcoded a "4" there but you get the picture. Valgrind told me about this.
Hmm, isn't it correct, since I specified GL_ALPHA, GL_UNSIGNED_BYTE?
i.e. for each pixel in the texture I'm only providing the alpha value,
each of which is a single byte.
> I wonder if we can completely get rid of the calloc. Basically, what
> this does it create a buffer filled with zeroes, then calls the
> (extremely slow) glTexImage2D with it. But the texture is never used
> since as next step you will usually lock it and initialize with bitmap
> data.
As the comment says, when I passed NULL to glTexImage2D, then draw the
bitmap, I can see some junk at the edges of the bitmap. You can try it
with ex_haiku: replace buf by NULL in that function, then run ex_haiku.
It should be pretty obvious.
But, yeah, there should be a better way to fix the problem.
Peter