| Re: [AD] New graphics API, take 2 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Shawn Hargreaves wrote:
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.
Right. It just seemed simpler to me to return a pointer than to re-write the
line pointers.
[snip]
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.
Yes, but I'd hate to see it turn into some huge object with 20 more vtable
entries. With a separate AL_DISPLAY and AL_BITMAP, I can simply do something
like:
al_set_str("/gfx/query/device", display->id);
(or al_set_ptr("/gfx/query/device", display)??)
al_get_int("/gfx/query/red_component_shift");
What I wanted to do was to eliminate the device/0, device/1, etc which was
also proposed, as it would involve string manupulation to loop through them.
Finally, if we have multiple displays, then we need the input mechanism to
be aware of it. mouse_x() and mouse_y() represent the mouse on which
display? Should we pass them a bitmap, or a display?
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...
Well, I'd consider using the init_dialog/update_dialog/end_dialog loop for
anything more complicated than a simple dialog (esp in games). That would
give the users more flexibility anyway. I don't see how or why a DIALOG proc
would switch the display bitmap...
[snip]
Finally, there's the icky issue of sub bitmaps. If the user declares a
subbitmap of the 'screen', then passes that to al_show_dissplay()
(al_show_bitmap?), then what? Copy only that sub-bitmap? Some display
mechanisms will have trouble doing that (page flipping, tripple buffering,
GL, tile accelerators). Do we leave it undefined? What if the user passes a
non-screen bitmap object?
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/