RE: [AD] No more video/system bitmaps

["Robert Ohannessian" <ROhannessian@xxxxxxxxxx>]

> In 4.3.x, where it is a complicated struct, I think it makes more
sense as state.


The struct is passed by reference though, so it's just as inexpensive as
an int on most systems. AL_COLOR is (at least initially) basically some
memory buffer containing the raw bytes for the color value. It's so we
can easily support > 32-bit color with ease.



> -----Original Message-----
> From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> developers-admin@xxxxxxxxxx] On Behalf Of Elias Pschernig
> Sent: Tuesday, June 21, 2005 12:14 PM
> To: alleg-developers@xxxxxxxxxx
> Subject: Re: [AD] No more video/system bitmaps
> 
> On Tue, 2005-06-21 at 20:46 +0200, Evert Glebbeek wrote:
> 
> > >
> > > al_select_bitmap(my_bitmap);
> > > al_set_color(1, 0, 0, 1); // red color is set for the context of
> > my_bitmap
> > > al_line(100, 100, 200, 200); // a line is drawn into my_bitmap
> > > al_select_bitmap(); // default output
> > > al_draw_bitmap(my_bitmap, 50, 50); // my_bitmap is drawn
> >
> > Heh... you know, that syntax actually reminds me quite a lot of
OpenGL.
> 
> It does? I don't think so. We already have state (e.g. drawing mode),
> and per-bitmap state (e.g. clipping rectangle). I'm not suggesting to
> have 100000 global state variables like OpenGL.. and yeah, color is a
> corner case. In the current allegro, where it is just an int, I think
it
> makes sense as a prameter. In 4.3.x, where it is a complicated struct,
I
> think it makes more sense as state.
> 
> > > And I think, also the color should be made a parameter of the
current
> > > context.
> >
> > I disagree. The current API is marred with _ex functions because we
> wanted
> > to get rid of a state-based system, remember? It's also not a good
idea
> > from the point of view of multi-threading. One might argue that it
is
> 
> But last time, we couldn't even find out who did that change, and
why..
> there are so many state variables still in use (some even by the
> software mouse drawer) that multi-threading is no argument..
> 
> > pretty dumb to draw to the same display from multiple threads
anyway,
> but
> > I think one could argue that it makes sense to draw to *multiple*
> displays
> > (or multiple display contexts) from different threads. Global states
are
> a
> > bad idea from this point of view.
> > Having states for display objects, on the other hand, would make
more
> > sense.
> >
> > I would still be opposed to the particular example of state-based
> colours
> > though, unless a strong case can be made in favour of them.
> >
> 
> Even if you have display objects with the state instead of bitmaps, it
> won't change anything with respect to multi threading. You either need
> to pass the display object to every drawing function, or else do
> locking, or use per-thread variables.
> 
> --
> Elias Pschernig
> 
> 
> 
> -------------------------------------------------------
> 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