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

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

It's an interesting idea. It would sure make the AGL code a lot simpler.


Alternatively, we can write the API this way, to reduce the object
management on apps:

	select_bitmap(my_bitmap); // Output to 'my_bitmap'
	putpixel(100, 100, ...);
	...
	select_bitmap(NULL);  // Return to default output
	

We would also need to restrict 'my_bitmap' so that it's not the source
of any operation while it is selected as the destination.



> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of
> peter.hull90@xxxxxxxxxx
> Sent: Tuesday, June 21, 2005 5:18 AM
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: RE: [AD] No more video/system bitmaps
> 
> 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/
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers