| Re: [AD] 4.3 display update methods |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wednesday 09 August 2006 07:28, Elias Pschernig wrote:
> Well, you still would have the update_rectangle call, so that's where
> the XSync would be done. If we require it to be a "front buffer", then
> each single putpixel command in Allegro would need to call XSync, or
> else we need again something weird like the line-by-line update hack in
> 4.2.
Or a flush command, ala glFlush. :)
> As I understand, the retained just means that you need to call al_flip
> before graphics updates get visible. So it is retained in that al_line
> won't immediately make a line appear, but only the next al_flip.
Ah. You mean double buffering, then. When I think of retained, I think that
it's kept after use (eg. something is retained for later use). I think
AL_DOUBLEBUFFER or some such would be clearer to indicate that the commands
won't be immediately visible.
> I was thinking about
> directly doing reads from the display with OpenGL, and never maintaining
> any internal buffer.
Exactly my thoughts. Put as little room between the APIs as possible. Just
enough for proper behavioral design.
> We would use GL_NEAREST while in allegro mode, so
> nothing unexpected should happen. If users use OpenGL, then I don't
> think it's a problem letting them deal with effects like AA themselves.
I don't think there'd be a problem being able to provide a generic methods to
hint at using AA, and other things you can assume from accelerated API
backends (such as linear resampling for stretch blitting). Just provide a way
to tell that the method failed if it's not available (or a display
capabilities flag to say the driver can't handle it).
> And if you make a game which uses e.g. getpixel(screen,x,y) for
> collision detection, then you could simply use your own memory buffer
> and blit that (either before al_flip in normal mode, or before
> update_rectangle).
I think such things should really be discouraged in an accelerated context,
where what you write may not be exactly what you get back. For such a setup,
IMO, you should have a seperate collision mask that you update and use with
your logic.. that just happens to be a memory bitmap. You shouldn't rely on
the display to be 100% exact with what you write to it.