[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Friday 28 July 2006 06:06, Elias Pschernig wrote:
> On Thu, 2006-07-27 at 15:28 -0700, Robert Ohannessian wrote:
> > I'll reiterate Shawn's point on the topic: It's best to think that
> > everything is a BITMAP.
>
> Well, in my view, I do not usually draw to a BITMAP so much, as to a
> DISPLAY (or surface, target, whatever you want to call it).
When thinking of terms of the new API, I don't think you'll ever be drawing
directly to the display (unless you can specify to draw to the front buffer
for dirty rectangles). You draw to an off-screen buffer/bitmap that the
display will use to copy/page-flip when you call al_flip_display();. With
OpenGL the target is a state that is almost always an offscreen buffer
(unless you call glWriteBuffer(GL_FRONT); ), which may give an illusion to
drawing to a display instead of a buffer, but IMO it's just that.. an
illusion.
> I think, there are three basic use scenarios for the new graphics API
> (all of which can be combined of course):
>
> 1. Pixel/Bitmap view. Users who use 320x240 or some other fixed
> resolution, and commands like al_putpixel, al_blit, al_line,
> al_getpixel. Just what you get with vanilla Allegro 4.2 when not using
> video bitmaps.
>
> 2. Sprites view. Users who will mainly use al_blit to do 2D graphics,
> probably expecting to be able to get accelerated blending effects as
> well as rotation and stretching. (Can't remember if we were going to
> have additional transformations in the new graphisc API right now.)
>
> 3. OpenGL view. Use the OpenGL API, which is vastly superior[*] to
> Allegro's, with the possibility to combine it with the above. I somehow
> have a feeling that 90% of users will prefer this, for example something
> like OpenLayer would sit on top of this as well.
>
> And the "everything is a BITMAP" view would basically be limited to #1,
> which is the least useful scenario.. pixel-oriented commands aligned to
> integer pixel boundaries.
I don't see why the "everything is a BITMAP" view needs to be limited like
that. OpenGL has FBOs which can be used almost exactly like an accelerated
BITMAP (like the "screen"). I don't see the problem with holding sprites as a
BITMAP either, especially since they can be moved to/from VRAM depending on
what Allegro thinks is best (and you'd blit the sprite BITMAP to the back
buffer BITMAP, which is later flipped to by the display).
> If we use a DISPLAY parameter, and also make it implicit like Peter Hull
> said, then everything will work the same for all three scenarios,
> without any hacks (and it would also solve the source/destination
> parameter confusion of blit).
Unless you want to use multiple buffers and combine them at a later stage..
which, for example, could be rather useful to emulators, which need to
emulate multiple hardware layers (1 layer = 1 off-screen BITMAP), or
home-brew compositing GUIs (each window has its own BITMAP target).