Re: [Alephmodular-devel] Drawsprockets?

[Br'fin <br...@ma...>]

On Tuesday, March 11, 2003, at 10:45  AM, Woody Zenfell, III wrote:
>> 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?

AlephModular does not currently hit either time point... careful timing 
or amazing speed rendering... I've set it to draw directly to the 
screen before. IT hurts your eyes and everything about the display 
flickers differently (walls and floors and then things flickering over 
already drawn areas :))

> 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.

That was the sort of target I was aiming for in my API. Aim for the 
flip and otherwise setup for the blip. Since the overall syntax follows 
the same flow... draw to this buffer and then tell it you're done :)


>> 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).

Terminals would still need to be setup to both buffers. Kind of amusing 
when you turn FPS on and the terminal is only drawn once, but other 
updates may occur. So it keeps drawing and redrawing the fps in the one 
corner, repeatedly overwriting itself :)

> 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?

That's fairly correct. I still need to work through the path that HUD 
updates are done in, but as of my update, both rendering and HUD are 
now drawn into the same buffer. And only one update needs to be flushed 
forward. The biggest issue right now is that HUD updates don't occur at 
the same time that the world is rendered in. So there's a very mild 
tear when you switch from full_screen to the 100% window (that is you 
toggle the HUD from being off to on) ... you have your 100% rendered 
view, then you have the remnant of the full_screen rendering and then 
the HUD appears in all its glory.

I am trying to emulate the page-flipping mode, so currently flushing is 
only clipped to the general drawing area. (That is, all of my current 
flushes cover the entire 640x480 space used for drawing) No attempts 
are made to handle dirty rectangles or the like. Though I may wish to 
make sure both fades and flushes are VBL synced.

-Jeremy Parsons