Re: [AD] Changes to aWiki

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> > My own view is that the destination for all drawing should be implicit
> > (so, for example, putpixel would be al_putpixel(x, y, colour) ) with a
> > function to select a particular bitmap as the destination. This is
> > because most drawing is done to the same bitmap (especially now that
> > the details of double buffering etc are handled by Allegro) and it
> > would also get rid of the strange parameter ordering between blit and
> > draw_sprite.
>
> I like this. An Allegro program could look like this:

I still don't like global states, but that could just be me. Part of the 
dislike is because it again introduces global variables and possible 
interdependencies of modules that we were trying to get rid of.

> Here, we always need the extra parameter (which can be confusing for
> al_blit), 

Not if the first one is always the target (or the source), I think.

> Advantages:
>  - saves repeating the same parameter all the time
>  - allows to use things like OpenGL textures or OpenGL render targets in
> an elegant and completely transparent way

How would this be different from a special kind of BITMAP?

> Disadvantages:
>  - "explicit is better than implicit" - although I don't think this
> applies here personally..

Will always be a matter of personal preference, I suppose. As said, I don't 
like the implicit states much.

> Other thoughts:
>  - Would need to take special care for threading. Probably each thread
> should have its own active display (put the _current_display global into
> thread local storage, or something like that, hopefully easy to do with
> pthreads).

Is it? I would have no idea how to do that...

> If two threads both select the same display, then they of 
> course need to do additional locking, just like with the other API. But
> two threads could work on different displays independently.

That is the same as when the display is passed explicitly, except that that 
case is probably easier to implement.

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/