Re: [Alephmodular-devel] Drawsprockets?

[Woody Z. I. <woo...@sb...>]

On Tuesday, March 11, 2003, at 09:11  AM, Br'fin wrote:

> On Tuesday, March 11, 2003, at 09:57  AM, Woody Zenfell, III wrote:
>
>> On Tuesday, March 11, 2003, at 12:57  AM, Br'fin wrote:
>>
>>> ... AlephModular currently uses a single back buffer that is always 
>>> getting copied forward (A window back buffer and appropriate flush to 
>>> display calls) I'm sure this will turn up cases of flicker (Places 
>>> where info needs to be updated on both buffers not getting updated 
>>> properly) ...
>>
>> Maybe it's because I just got up, but I don't see how this scheme 
>> could result in flicker?  ...
>
> Right, the current environment is not page-flipped. But I don't know 
> how DrawSprockets or SDL or Windows handles fast screen updates. 
> DrawSprockets appears to use concepts of fore and back buffers with a 
> swap command. CGDirectDisplay actually seems to act like the classic 
> Mac-way of handling fast screen updates, go figure. :)

Are there really any alternatives (that protect us from flashing and 
tearing) to render-offscreen-then-blit and render-offscreen-then-flip?  
(I assume the former is what you're calling the classic Mac-way.)  Well 
ok if your application were really carefully timed and quick to render, 
I guess you could render straight to the screen when the raster's not 
looking, but in practice that's going to be quite a pain I think?

FWIW, IIRC SDL and DirectDraw both use page-flipping if possible, and 
emulate a flip() with a blit if flipping is not available.  I think.  Of 
course you can find out which is actually going to happen by querying 
capabilities and examining flags etc.

> If any one of those environments is page-flipped, then I bet that I 
> will find some flicker problems. Most notable around the HUD which has 
> classically been drawn to the screen_window instead of using the 
> world_pixels that actual rendering used.

Agreed the HUD is going to be the main concern in a flipping 
environment.  Well, and the GUI (dialogs etc.).  Terminals might be an 
issue I guess but also very well may not; IIRC they tend to redraw the 
entire terminal area on each update (even if updates only come once per 
terminal page instead of at 30fps or whatever).

So I assume currently world_pixels is typically a ClippingBuffer of the 
offscreen buffer, and HUD updates etc. are rendered into another part of 
this bigger offscreen buffer (ah, probably via another ClippingBuffer, 
yes I am seeing it), and once per frame either the world_pixels rect or 
the entire drawable area's rect (depending on whether the HUD updated) 
is blitted ("flushed") to the front buffer?  Hmm no that last bit isn't 
exactly right, what if the player is reading a terminal and gets hurt?  
His HUD needs to update even though his world_pixels didn't.  I guess 
then any of the four combinations of world_pixels and hud_pixels (or 
whatever) could be "flushed" in a given iteration.  How do you keep 
track of which combination needs to be flushed?  Dirty flags?  Or do 
they flush separately, immediately after rendering finishes in one of 
them?  It seems this latter strategy could either result in tearing (if 
the "flush" logic doesn't wait for a time when the raster's not looking) 
or excessive waiting (if it has to wait for the raster once to flush the 
world_pixels, then wait again before it can flush the hud_pixels).  
Maybe.  Depending on how the flush actually works.  Hmm maybe the flush 
routine doesn't really do the flush, but updates a dirty-rectangles list 
for the next raster-safe time.  Oh no, that wouldn't work because then 
you could potentially draw into the back buffer too soon, hmm, unless 
blitting to and locking the back buffer wait for the flush before they 
can start.

BTW random off-topic but related question: anyone know how the concepts 
of raster and refresh rate apply (or don't) on flat-panel displays like 
TFT, plasma, etc.?

Woody