[Scummvm-devel] Framebuffer

Marcus Comstedt marcus at mc.pp.se
Mon Oct 23 23:46:44 CEST 2006


Max Horn <max at quendi.de> writes:

> Now, what do you our porters say? I'd like to hear whether this move  
> would complicate or simplify your code -- or neither (besides the  
> fact that you'd have work to make the transition, of course). And  
> would it likely cause a speed penalty, and improvement, or again,  
> nothing?

In the Dreamcast backend the copyRectToScreen function just copies
into an offscreen buffer, and then updateScreen sends all of it to the
graphics pipeline (no dirty rects handling, the 3D hardware renders
each scene from scratch anyway), so it doesn't matter at all if the
modification of the offscreen buffer is done by the backend or the
engine.  I do need to know when to send the data though, each frame
sent will occupy a rendering slot, and on an NTSC system I have 60 of
those per second (50 on PAL).  If I try to send more, the pipeline
will stall.  So I need some kind of indication (call it updateScreen,
unlockScreen or whatever, but remember that for cursor updates to work
it needs to be called regularly even if nothing in the background
changes) when a frame is complete and a "page flip" is in order.

Another thing to consider is palette animation, if updateScreen is
removed, how would you indicate that you want the scene redisplayed
with the same contents but a new palette (for e.g. a fadeout)?  If
setPalette and unlockScreen each separately triggers a redisplay, you
won't be able to do a clean cut to a new scene with a different
palette.


  // Marcus






More information about the Scummvm-devel mailing list