RE: [AD] Changes to aWiki

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


On Mon, 2006-02-20 at 12:39 -0800, Robert Ohannessian wrote:
> Uggh. Let's stay away from pbuffers, please! A context per render target
> is hard enough for our driver to manage. We don't need such extra
> complexity in Allegro.
> 

Well, in the OpenGL driver, we will need to:

- use textures to store bitmaps, for efficient rotated scaled alpha
bitmaps (i'm not sure you can get that with something like CopyPixels..)

- allow to update those bitmaps, also with OpenGL

So, my assupmtion was, "pbuffers" is what we need. Is there something
else? We wouldn't need a complete OpenGL context of course, just a way
to draw to an off-screen target in VRAM - so another simpler extension
allowing that would be fine.

But the current AllegroGL way of doing the operation on a memory bitmap,
then re-uploading a texture, really is bad. So if it is at all possible
to do it in an OpenGL way, we should try to put that in. It wouldn't
need to be in the initial driver, but the API should allow the
possibility.

If my view of the issue above is correct (and quite likely it's not, I'm
not an OpenGL expert at all) - how much extra complexity would it be? I
was assuming it's rather simple, something like:

al_opengl_driver_create_surface(w, h, format, flags) {
   ...
   if (flags & BITMAP_NEEDS_TO_BE_UPDATED_A_LOT) {
      opengl_data->context = glx_create_context() // or whatever is needed
      surface->vtable->blit = al_opengl_driver_blit
   }
   else {
      surface->vtable->blit = slow_memory_blit_then_texture_upload
   }
   ...
}

-- 
Elias Pschernig





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