RE: [AD] New graphics API, take 2

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Bob writes:
>> Why is AL_DISPLAY different to AL_BITMAP? 
> 
> The rationale was that Allegro would keep a table of bitmaps 
> somewhere to represent, for example, all three buffers of a 
> triple buffer display.

That could all be handled internally, though. For some drivers
just altering the line pointers during the flip operation would
be enough to do this, or on others toggling whatever internal
ID or handle is used to access the display.

This would require a good extensible system for drivers to 
attach custom data to bitmaps, but that is needed anyway
(the current single "extra data" pointer is probably enough
as long as each bitmap is only owned by a single driver).

Doing all this through bitmaps just seems nicer to me, as
there is already a 1<->1 mapping between a display and the
bitmap you get from locking it, so why not merge them into
the same object? Bitmaps are already extremely polymorphic, 
and can only benefit from becoming more so if extra things 
need to be added to support them doubling up as display
surfaces.

Consider the case where a GUI dialog manager has been written
to render itself onto a display object (a reasonable choice,
especially if the GUI is in control of the event loop for long
periods of time so needs to do the page flip calls itself at
regular intervals), but then someone wants to change it to
render onto a memory bitmap for whatever reason. This sort
of alteration would be far easier if all you had to do is
provide a different bitmap as the render target...

>> I find the name al_update_display() confusing.
> 
> I agree, but I didn't have any good ideas on to call it. 
> show_user_contents_of_this_bitmap() seems a bit too much :)

Yeah :-)

>> I think the D3D name is best: "present" means to do whatever is 
>> required to present the results of your drawing so they will be 
>> visible to the user.
> 
> Perhaps ->show() would be more adequate. I read it as "the 
> present" when I first read the mail :)

D3D documents this as:

	IDirect3DDevice8::Present
		Presents the contents of the next in the sequence of back
		buffers owned by the device. 

Which is weird, because although the name Present is nicely
agnostic as to page flipping vs. double buffering vs. whatever,
the explanation then seems to be assuming a page flipped 
configuration.

Anyway, it seems generally sensible to borrow terminology from
other places wherever possible, as the fewer different terms
in use for the same thing, the less likely people are to get
confused.

> show() would also go with the naming that Allegro is 
> currently using, which may be beneficial in some sense.

Good point. Borrowing terminology from older Allegro versions
makes at least as much sense as trying to be consistent with
D3D and GL.


-- 
Shawn