RE: [AD] No more video/system bitmaps

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


On Wed, 2005-06-01 at 08:39 -0700, Robert Ohannessian wrote:
> 
> How is that any different? Allegro would have to do the exact same work.

Of course, and that's the reason for it. The usage hints already make
Allegro do this kind of work. Just, normally, you only specify the usage
once at creation time, and then there's no more control over it. The
above simply would give more control in the case like the above, where
Allegro would get it wrong otherwise, since no "flip" calls are made to
evaluate access statistics.

> > 
> > Or a per-display list? Maybe each AL_DISPLAY would have its own OpenGL
> > context as well.
> 
> 
> How do you associate a random AL_BITMAP* to an AL_DISPLAY? There is no
> current AL_DISPLAY if you are running multiple windows.

Hm. I'm not sure, but I have a feeling all but memory bitmaps will need
to know to which AL_DISPLAY they belong.. but well, if not, then all the
better. Then you could just blit the same bitmaps into different
AL_DISPLAYS, which would be nice for sure.

It's only, I somehow assumed each window needs it own OpenGL context and
therefore each AL_DISPLAY, and therefore also the AL_BITMAP must know to
which AL_DISPLAY it belongs..

> In VBO, COPY makes some sense. It hints that you'll use glBufferData() /
> glBufferSubData() to define the VBO, and not glMapBuffer(), which may
> result in the VBO being copied out of video memory and into system
> memory so that it can be directly addressable by applications.
> 
> It makes a little less sense for Allegro, since there is no
> straightforward way to define a bitmap's image data, and also most
> drivers can map video memory directly.
> 
> That's the main reason I left it out.

Ah, ok.

What would correspond to my idea of "Copy" then? I.e. a bitmap to which
I need no direct write access, but to which I e.g. blit() a lot. Using
the 6 usage patterns, the above case would be DYNAMIC_DRAW (I need no
direct read access, but it changes often). But DYNAMIC_DRAW is already
what I would use for a bitmap which I often acquire for direct write
access.. so DYNAMIC_DRAW would mean it has to be in system memory, to
have fast direct access. In the case where I only blit() to it, it
should always stay in video memory though, although it is being written
to every frame..

> > But then, I'm somewhat confused by it all right now :P
> > 
> > So, when this goes into Allegro, we should have an entire chapter for
> > it, with a lot of concrete usage examples..
> 
> 
> I wonder if that wouldn't be to get old users to understand how it all
> works, instead of actually explaining it to new users. After all, the
> whole idea is that users shouldn't care where bitmaps live; Allegro
> would just do The Right Thing(tm).
> 

Yes, that's what I meant. For each usage, have an example of a bitmap
which is used for something, and explain which of the usage patterns it
should be given initially, and why. This would *not* explain to old
users how an old-style driver (or any driver) would implement it, just
explain to new users how to use it.

Something we should avoid is that users, instead of having to care where
the bitmaps live, like with the current Allegro, they now have to care
what usage pattern to assign (even if it is only the initial
assignement, and changes automatically). It should be very clear from
the documentation when to assign which usage pattern. Of course,
ideally, there would not need to be any parameter, or just always an
AUTO pattern as was suggested..

-- 
Elias Pschernig





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