Re: [AD] Changes to aWiki

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




On 20/02/06, Evert Glebbeek <eglebbk@xxxxxxxxxxxxxxx> wrote:
> > 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.

OpenGL works this way and it doesn't have global variables - or do you mean internally?

> 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.

Currently, draw_sprite is the other way around, though.

> 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?
I think it would hint to the user that some work is going on behind the scenes. I'm assuming that changing the context (or render target in DirectX speak) is a non-trivial operation. As it is, blit(screen, mem, ...) and blit(mem, screen, ...) appear to be symmetrical operations and they aren't really for modern hardware (they were, of course, when Allegro was devised)


> 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...

I guess we should handle multithreading if the underlying implementation can. I think it's OK in Mac's OpenGL, but you need to pass a flag to do it in DirectX.

Pete




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