Re: [AD] Changes to aWiki

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-02-20, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Wed, 2006-02-15 at 17:48 +0000, Peter Hull wrote:
> > Now I'm confused. Does it return AL_DISPLAY or AL_BITMAP? If the
> > former, why is it called al_create_display_bitmap?
> > 
> > My own view is that the destination for all drawing should be implicit
> > (so, for example, putpixel would be al_putpixel(x, y, colour) ) with a
> > function to select a particular bitmap as the destination. This is
> > because most drawing is done to the same bitmap (especially now that
> > the details of double buffering etc are handled by Allegro) and it
> > would also get rid of the strange parameter ordering between blit and
> > draw_sprite.
> 
> I like this. An Allegro program could look like this:
> 
> ----
> AL_DISPLAY *display = al_create_display(640, 480, 0, 0, 0);
> al_line(0, 0, 100, 100, RED);
> AL_BITMAP *bitmap = al_create_bitmap(100, 100, 0, 0, 0);
> al_select_bitmap_display(bitmap);
> al_line(0, 0, 100, 100, BLUE); 
> al_select_display(display); 
> al_blit(bitmap, 50, 50);
> al_refresh_display();
> ----
> 
> al_create_display would make the newly created display the selected one,
> and subsequent commands could access it. This also applied to
> al_create_bitmap, in case it needs to display (e.g. for video bitmaps).
> al_select_display would implicitly de-select the previous display, for
> example if a modified bitmap needs a texture upload, or maybe to
> gl_flip() on the OpenGL context of the bitmap..
> 
> With the original proposal, the same would be like:
> 
> ----
> AL_DISPLAY *display = al_create_display(640, 480, 0, 0, 0);
> al_line(display, 0, 0, 100, 100, RED);
> AL_BITMAP *bitmap = al_create_bitmap(display, 100, 100, 0, 0, 0);
> al_line(bitmap, 0, 0, 100, 100, BLUE); 
> al_refresh_bitmap(bitmap)
> al_blit(display, bitmap, 50, 50);
> al_refresh_display(display);
> ----

??? Which proposal was this?  It seems to imply that an AL_DISPLAY
is really the same type as an AL_BITMAP.

> Here, we always need the extra parameter (which can be confusing for
> al_blit), and also need to pass it to al_create_bitmap, just in case.
> And we need an explicit command to tell we are done with updating a
> bitmap, in case its driver needs an action performed. (Mere memory
> bitmaps is something which will still exist in 4.3, but e.g. for the
> OpenGL driver, hardly would be used at all.. so must think in a new
> pattern here I guess.)
> 
> So, summarized:
> 
> Advantages:
>  - saves repeating the same parameter all the time
>  - allows to use things like OpenGL textures or OpenGL render targets in
> an elegant and completely transparent way
> 
> Disadvantages:
>  - "explicit is better than implicit" - although I don't think this
> applies here personally..

Well, I don't like implicit state.

However, I can see that it might have some advantages from a user's
perspective (as in your "OpenGL textures or OpenGL render targets"
comment).  From an implementation POV, it's probably not a big
difference: what would have been a vtable in the AL_BITMAP type is moved
further into the internals so the user never sees it, but otherwise will
probably be a vtable anyway (although we could use a big switch
statement, or whater, to branch to the correct function given the
currently-selected target).

Peter