[AD] proposal to acquire_screen() and release_screen() |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
the user programs could always make use of acquire_screen() and
relese_screen() in MAIN drawing routines like?
void main(...)
{
...
while(!done){
handle_input();
handle_ai();
...
acquire_screen();
draw_background(); /* no calls to acquire_screen() */
draw_enemys(); /* or relese_screen() */
...
draw_player(); /* into theses routines */
release_screen();
...
}
...
}
i sugest the uses this, easy implemetation of doublebuffer, pageflipping,
triple buffer or windowed modes. the user program could call any new
function like.
...
set_gfx_buffering(ALLEGRO_BEST_MODE);
...
then allegro could attempt to set better mode avail, like triple_buffer, or
any other requested, and user program could use allegro routines to draw to
screen bitmap without know how implement triple_buffer the calls to
acquire_screen() or release_screen() will make all work.
release_screen() /*generic sample for triple buffer*/
{
set_next_active_buffer(screen);
workbuffer++;
if(workbuffer>_num_work_buffers)
workbuffer=0;
screen=buffers[workbuffer];
}
release_screen() /*generic sample for windowed mode*/
{
/*screen could be an memory bitmap or hidden video memory area*/
blit_bitmap_to_allegro_window(screen);
}
this will help to implement some features in mac port,
-windowed mode,
-any color conversion to desktop,
-acess to acelerated double or triple buffer,
-pageflipping,
-virtual screen size and scrolling,
-scaling ie an 320x240 fill an screen with 640x480,
-system dirty rectangles *,
i can't now implement this features because isn't many information about mac
hardware.
* an needed feature is dirty rectangles many games in mac use to speed up,
it's OK, because is an feature present in DrawSprocket library.
i know about drastic changes which this will make ,but is only an proposal
PS. how work the windowed drivers, how them handle windows overlaped or area
not visible or need for system update events?
Ronaldo