Re: RE: [AD] No more video/system bitmaps

[<peter.hull90@xxxxxxxxxx>]

I have been thinking about this a little bit, and I have a suggestion. When Allegro was designed, the concept of the BITMAP was one of its main strengths. It allowed the user to blit to and from system RAM and video RAM without having to worry about the details of bank-switching and so on. At that time, video cards just provided a block of memory and not much else. From this, Allegro could manage the screen, and use anything left over for a second page or for video bitmaps.

These days, graphics cards are much more sophisticated, and are accessed via DirectX or OpenGL. I wonder if it is time to stop treating the screen as a block of memory, and remove the 'symmetry' of the blit function with respect to source and destination. 

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.

The user should be aware that create/destroy_context could be slow. Once a bitmap no longer has a context pointing to it, it can be considered read-only, and can be moved, by Allegro, to VRAM. This will allow the fastest possible blitting. Of course, another context could be opened on it later, if it needs to be written again.

In some cases, the user would want to write frequently to a bitmap, without the overhead of the create/destroy_context calls. An example might be a SNES emulator. In that case, the context should be held open, and flush_context called.  Example:

CONTEXT* ctx=create_context(my_bitmap);
while (is_running) {
 select_context(ctx); // draw to bitmap
 putpixel(100,100, makecol(255,0,0));
 ...
 flush_context(ctx);
 select_context(screen); // go back to drawing to the screen
 blit(my_bitmap, 0, 0, 0, 0, my_bitmap->w, my_bitmap->h);
 al_flip(); // Actually update the display
}
destroy_context(ctx);

This is not as neat (3 extra lines of code from current) but I think this would be a less common case. When the context is held open, the bitmap is 'pinned' in main memory, so Allegro would not keep transferring it to VRAM.

In fact, al_flip() could be a synonym for flush_context(screen) - basically it's the same kind of operation.

Note that there are no separate memory bitmaps and video bitmaps. If a bitmap has a context open, it probably would be in system RAM. If it has no context open, it might be moved to VRAM. 

I think this would work, what do others think?

Pete

> 
> From: "Robert Ohannessian" <ROhannessian@xxxxxxxxxx>
> Date: 2005/06/16 Thu PM 07:19:50 GMT
> To: <alleg-developers@xxxxxxxxxx>
> Subject: RE: [AD] No more video/system bitmaps


-----------------------------------------
Email provided by http://www.ntlhome.com/