Re: [AD] No more video/system bitmaps

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> Furthermore, the vast majority of graphics operations in Allegro programs 
(or at least, the ones I've seen), have either the screen as a 
destination, or a large memory bitmap acting as a double buffer. With the 
new API, the latter case will be handled by Allegro itself.
> 
> Therefore, my suggestion is to _remove_ the 'destination' argument from 
all graphics operations and have default destination instead. I have 
called this a 'context,' which is what OpenGL and Win32 call it. Example:
> 
> putpixel(100,100, makecol(255,0,0)); // draw a point to the screen
> al_flip(); // actually update the display
> 
> This would be the most common usage. Of course you should be able to 
change the context, to draw to a bitmap. For example:
> 
> CONTEXT* ctx=create_context(my_bitmap);
> select_context(ctx); // draw to bitmap
> putpixel(100,100, makecol(255,0,0));
> ...
> select_context(screen); // go back to drawing to the screen
> destroy_context(ctx);
> 
> A context could be created from a bitmap as above, or it could be a 
window (allowing multiple windows) or a different monitor (allowing 
multi-headed displays) - in this sense it's like the AL_DISPLAY that has 
been talked about.

Fascinating.

How about having an AL_DISPLAY * object as the destination argument rather 
than an AL_BITMAP, and add a function to create an AL_DISPLAY from an 
AL_BITMAP? Of course, that will then open the door to an 
AL_DISPLAY->AL_DISPLAY blitter, which comes down to the sort of thing we 
were trying to avoid in the first place.
The solution would be to keep that door shut, of course ;)

The DISPLAY could have methods like DISPLAY->blit_to_me, 
DISPLAY->line_on_me, DISPLAY->put_pixel_on_me and the BITMAPs need never 
care about that.

As I said in another message, I don't like the idea of a global state. 
However, I do like the idea of a state associated with a DISPLAY and a 
DISPLAY as something you can draw on.

> I think this would work, what do others think?

I like the idea. If no one else is already doing so, I'm going to have a 
look at what the current A5 graphics API looks like and what's already 
been done on that and see how an API like this would work out based on the 
proposed functionality.

Evert