Re: [AD] Changes to aWiki

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2006-02-20 at 23:02 +1100, Peter Wang wrote:
> > 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.

Ah, yes, I forgot something like (from current 4.3):

AL_BITMAP buffer = al_get_buffer(display);

And all the cases above who draw to "display" should draw to "buffer" -
but besides that, it should stay the same.

> 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).

Yes, just having the implicit display should be no big difference. And
where I used AL_DISPLAY, it would be more like the current AL_BITMAP.

Like, if you set the display to point to a 16-bit memory bitmap, then
that display's vtable entry for ->line would point to the 16-bit-memory
line drawer. If you select the OpenGL display again, that would point to
a vtable with a glBegin(GL_LINE).

In short, my AL_DISPLAY would contain both the entries from GFX_DRIVER
and GFX_VTABLE, while in the current 4.3 API, AL_DISPLAY has GFX_DRIVER,
and AL_BITMAP would have GFX_VTABLE.

-- 
Elias Pschernig