RE: [AD] No more video/system bitmaps

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> A question I had about this whole thing, is what does
> the flip function do?  I couldn't tell from this
> description, and I think new users will have the same
> problem.

They won't if it's documented (as it will be). In principle it's similar to
allegro_gl_flip(): it makes the backbuffer visible.
Short example pseudoish code snippet:

AL_BITMAP *screen;
AL_DISPLAY *dpy = al_create_display(AUTODETECT, TRIPLE_BUFFER, 16, 640,
480);

/* Graphics update */
screen = al_get_buffer(dpy);
/* blit stuff to the `screen' bitmap */
...
/* flip front and back buffer */
al_flip_display(dpy);

> If its a function to replace the current
> request_video_bitmap / show_video_bitmap functions,
> then maybe it should be named someting less vague like
> set_al_display(AL_DISPLAY *env, AL_BITMAP *bmp).

I don't think we need request/show_video_bitmap anymore, but I don't
remember if they are supposed to be deleted. At any rate, I disagree that
it should take an AL_BITMAP parameter, especially with the current plan.
Perhaps it could be argued that some users will want to bypass Allegro's
handling of the update chain and get acces to the individual pages (which
doesn't imply direct acces to video memory!) and would want such a
function, but that can then be added. I think the current new API should
satisfy most users in this respect though (it certainly satisfies me).

> On another note, I'm not sure how much I like this
> idea.  It would involve (or at least its begining to
> sound so) putting in counters / checks in every
> function that affects and / or reads bitmaps,
> potentialy taking a long time to swap where the
> bitmaps live in memory.

Well, I agree that I don't much like the idea of to much going on behind
the user's back without his or her consent. I do think we can let Allegro
handle bitmap storage based on usage, but only if the user requests it. In
other words, I think the user should manually call an
al_optimise_bitmaps(), say after calling al_flip_display() (or less often
if they so choose).
(off-topic: if we want to spell that as al_optimize_bitmaps() perhaps
someone should keep a watchful eye on patches I may make for this).

> What if I as a user need to
> do a quick getpixel or something, and all of a sudden
> my game freezes for a second or two.

Well, in that case, I think one could argue that the code is poorly
designed.

> 1) Performance hits.  I think allegro should be very
> carefull here.  Reputations are gained extremely
> easily, and hard to shake.  If there are more games
> out there that pause randomly with an Allegro logo on
> it, then SDL will completely take over.  Also the
> developers of those games wont like such uncontrolable
> delays.

True, but I'm not sure the hit will be too high in this case. At any event,
it will be a while yet before Allegro 4.3 is stable enough to do real games
with it where this may eb an issue.

> 2) Messiness.  Its just plain messy to be putting a
> hook into tons of differen't functions.  And what
> happens when one of the drawing functions calls
> another one?  Its fixable but its still just a really
> messy idea.

This is in my opinion a more serious concern. Less messy code is easier to
maintain.

Evert