Re: [AD] OpenGL

["Peter Hull" <peterhull90@xxxxxxxxxx>]

I would say the usage scenarios are: (talking about Graphics only)
1. Using only Allegro commands
Allegro will implement these in the best way it can for the underlying
platform - which may OpenGL, D3D, framebuffer... Whatever, it will be
guarenteed cross platform. So, if we include anti-aliasing commands,
for example, they'd have to be implemented for every underlying
platform.
2. Using Allegro like GLUT
Once you've got your window open, it's 100% OpenGL commands from then
on. More capable API but may not be cross platform.
3. Mixing the two
AllegroGL has commands to create textures from bitmaps and create
fonts. In scenario 1 you can still do accelerated blits, but in this
scenario you'd be getting the actual GL texture object.
It also (maybe less usefully) has allegro_gl_set_allegro_mode() which
allows you to mix GL drawing and allegro drawing.
To use option 3 you have to be a bit careful - it's probably possible
to get OpenGL into a state where the Allegro implementation doesn't
work right.

On the implicit target vs everything is a bitmap, I just think it's
worth it to shorten all those functions calls, and also to encourage
coding that could be accelerated.

Pete


On 7/28/06, Elias Pschernig <elias@xxxxxxxxxx> 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).
>
> 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.
>
> 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).
>
>
>
> [*] For example, try to make a most simple 2D scroller with integer-only
> display coordinates, as is the only possibility in Allegro 4.2. It will
> never look as smooth as one which uses proper interpolation with
> floating point positions. (And even though internally, OpenGL has to use
> a fixed resolution and at the end produce pixels as well, this is not
> the view the user has of it.)
>
> --
> Elias Pschernig
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers