[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 2006-02-22 at 00:21 +1100, Peter Wang wrote:
> > I agree. If there's any good reason to keep the display target
> > parameter, then I would change my mind.. so really, not much need for a
> > poll, except to have it discussed.
>
> You already know what Evert and myself think of implicit state.
>
> One technical reason is that, most likely, a target parameter _will_ be
> threaded through the Allegro internals, and having deal with this
> disparity with the user-level API introduces more complexity into the
> internals, not less (perhaps only to a small degree). This is a big
> assumption but I think it is defendable since we know how badly state
> interacts with threads.
Well. I think, all the vtable entries could have a target parameter,
like this:
al_line(x, y, z) {
active_display->vtable->line(active_display, x, y, z);
}
> Though it honestly doesn't matter too much anymore, as I assume OpenGL
> will be the graphics API of choice for future Allegro programs.
I doubt that. If I use Allegro, then the reason is most likely that I do
not want to deal with all the complexity of something like OpenGL. And
if I need 3D transforms, shading, and everything else, then I probably
wouldn't use Allegro at all. Allegro's place in my idea is just where it
already is: A simple 2D graphics API, which takes the complexity of all
the internals (of e.g. an OpenGL driver) away from the user.
For example, if we will have OpenGL FBOs, then the user can just create
a bitmap, render something to it, then render the bitmap somewhere.
About 3 lines of simple, understandable code. And no need to care about
all the extension querying and OpenGL state management running in the
back.
--
Elias Pschernig