Re: [AD] min/mag filters

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2010-08-14, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> On Fri, 2010-08-13 at 10:42 +1000, Peter Wang wrote:
> > > 
> > > But not sure, maybe we want this as a display flag instead of bitmap
> > > flag? So I better ask here before I go ahead.
> > 
> > Tentatively, I think the display flag would be better, otherwise we
> > would need to call glTexParameter for every new source bitmap, right?
> > Or does the flag apply to the destination bitmap?
> 
> It's in the per-texture state, so it's the other way around - we'd have
> to change it every time if we keep it as per-display state. (It may be
> different with D3D though. Since the HW is the same in both cases, I
> guess it doesn't make much difference, performance-wise.)

Seems I misunderstood GL, yet again.

> > On a practical note, a lot of code is likely to call
> > al_set_new_bitmap_flag(ALLEGRO_VIDEO_BITMAP) without or'ing it
> > with the old flags. 
> > 
> 
> Hm, true... but that just means our al_set_new_bitmap_flag function may
> be hard to use correctly and having only a single flag available so far
> made that not obvious. Maybe it should work like al_toggle_display_flag.

I don't know if it would help that much.  Right now, almost the only
reason for me to call al_set_new_bitmap_flags is to create a memory
bitmap, and in that case I want to restore the old flags afterwards.
It would be most convenient to provide al_create_memory_bitmap.

> Anyway, about the filtering, my use case works like this. I have my
> Mario sprite in my game who should scale up smoothly, so I set his
> magnification filter to linear. I also have a small minimap which has
> one pixel per tile and I display it scaled up like 8x or 16x. This can
> *not* have a magnification filter or you'd just see something blurry.
> 
> So for that, it would be easier to set the filtering on a per-bitmap
> basis - else I'd always have to change display filter state in my
> drawing function.

Yes, I see.

> > > Also, we might want to add another flag:
> > > 
> > > ALLEGRO_MIPMAP
> > > 
> > > When you scale bitmaps out then that's almost a must to use. Mipmaps are
> > > automatically updated with opengl es 1 when you use glTexImage2d so it's
> > > just another flag to add to glTexParameter. (I don't know what happens
> > > when you modify the texture with FBO, or how it works in other opengl
> > > versions or in D3D though).
> > 
> > Perhaps mipmaps should be on by default, and add the flag
> > ALLEGRO_NO_MIPMAPS if you know you won't be scaling a particular
> > bitmap.
> > 
> 
> They use twice the memory though and always require power-of-two sizes.
> Also, drawing into bitmaps with a mipmap likely is very slow. So better
> do it only when requested.
> 
> I only said "must use" while thinking of something like completely
> scaling out a checkerboard... with mipmaps that will scale out naturally
> (to a gray pixel) while without it will cause horrible flicker :P (no
> matter if filtering is nearest or linear).

I have no objection.

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/