RE: [AD] Changes to aWiki |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> 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?
Yes! This is what FBOs are for.
http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.t
xt
> 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.
I totally agree, but FBOs (nor pbuffers) are available everywhere. So we
do need to have a codepath for the case where we need to draw into a
memory bitmap and reupload a texture.
> It wouldn't
> need to be in the initial driver, but the API should allow the
> possibility.
Allegro currently gives us this possibility. Or perhaps I misunderstand?
>
> 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
> }
> ...
> }
I don't see why you'd need this. Always construct an FBO if you can.
Avoid pbuffers (they're evil).