Re: [AD] set_display_mode and screen update handling

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sat, 2004-07-31 at 16:46 -0700, Chris wrote:
> > If you request: TRIPLE_BUFFER | PAGE_FLIP, should it do page flipping if
> > triple buffering isn't possible?
> 
> That's what my code currently does, yeah.
> 
> > I think, the bpp could be defines as well.
> 
> Then the question comes in, as to what should have priority? 
> Windowed/fullscreen or bitdepth? If the bitdepth and screen mode combo 
> isn't available, should the screen mode switch first or bitdepth?
> 

True.

> > I guess the vs should be not a parameter here, but specified in the call
> > to set_display_mode. After all, it has no meaning for anything but
> > double buffer.
> 
> Hmm.. perhaps it should be another function altogether? I don't like the 
> idea of having to reset the gfx mode just to toggle vsync.
> 

The same goes for switching between page-flipping and double-buffering.
I think we could set_display_mode remember the last values, and when it
is called again, and only the update method changed, only do what's
necessary to change that.

> > Very often, you also need the front buffer. E.g. when doing page
> > flipping, but then you use the GUI file selector. screen could be the
> > back page in that case. With my method, there'd be 3 global variables to
> > get up to 3 pages (or just a wrapper get_front_page would do as well).
> 
> Again, these names are a little ambiguous. If you're doing something 
> like Allegro's GUI (dirty rectangles), then I'd think you'd either use 
> no buffering, or double buffering (making sure to blit the buffer 
> whenever it changes), or to blit the current screen to the current 
> buffer (which would be fast since it'd likely be vram->vram 
> accelerated), modify that, and then show the new buffer.
> 

Well, just an al_get_front_buffer would work as well. It would return
the video bitmap currently being displayed, so you can set screen to it
before calling a GUI function.

-- 
Elias Pschernig