[Scummvm-devel] Minimal screen updates and possible OSystem improvements

Vladimir Menshakov whoozle at yandex.ru
Tue Nov 10 17:44:00 CET 2009


So another real world example, allowing quick porting of the TeenAgent engine to the new api. 

TeenAgent has several layers: 
1) background
2) animation slots 0-3
3) custom animation slots 0-3
4) actor
5) foreground slots (different numbers per scene)
6) foreground overlay. 1

All animation and sprites uses colorkey 0 for transparent pixel. 

So the render cycle in unoptimized engine looks like
1) copyRectToScreen(background)
2) render all animations ( using lockScreen, as OSystem does not have colorkey blit). 
3) render messages (using lockScreen again)
4) updateScreen(), wait and goto 1. (we have 1-2 fullscreen memory copying for each frames depending on backend). 

How could we optimize it? Let's add generic class: 

ScenePlanner {
void add(rect) {
   for(i = dirty.begin(); i != dirty.end(); ++i) {
     if (i->contains(rect)) 
       return;
     if (i->intersect(rect)) {
       i->extend(rect); //simplification, just for concept illustration. 
       return;
     }
  }
  dirty.push_back(rect);
}};

So, optimized scene would look like: 
1) for each rectangle from planner call copyRectToScreen().
2) render all animations (LockRect(animation_frame, Read | Write) for colorkey blit), adding rectangles to planner.
3) render messages, adding bounding boxes to planner
4) wait and goto 1. 

Backend would collect dirty rectangles and blit it with hardware or software to backbuffer or directly to video memory - we could tune it for each platform. 

No backbuffer in engine, no extra surfaces allocated in engine, removing custom tricky logic from each engine. Less code - less bugs. 
PROFIT 
:)

10.11.09, 16:54, "Max Horn" <max at quendi.de>:

> Am 10.11.2009 um 16:33 schrieb Vladimir Menshakov:
> > Oh, let's try from the very beginning.
> > Let's divide engines (from scummvm and future ones) into three groups:
> > 1) LockScreen() -> draw something -> unlockScreen(). Fullscreen  
> > update on every frame. Backend does not know about modified pixels.
> > 2) Creating backbuffer, draw everything in it.
> >  a) Blit backbuffer into screen. 2 fullscreen updates on every frame.
> >  b) Blit dirty rectangles with copyRectToScreen, Fullscreen update +  
> > bunch of rectangle updates.
> > 3) Creating surfaces for every dirty rectangles (colorkey blit into  
> > it), then later call copyRectToScreen.
> >
> > Backends maintains:
> > 1) its own dirty lists for blitting
> > 2) its own backbuffer. or not. :)
> >
> > So we have multiple variation of dirty rectangle code everywhere on  
> > every level of graphics code.
> >
> > Adding LockRect solves many problems for engines as it informs  
> > backends about rectangle modified by pixel update.
> >
> > 1) We could blit actors/cursors/animation colorkey or alpha-blending  
> > sequences without fullscreen updates every time.
> > 2) No extra 'dirty surfaces' code in engines.
> > 3) Actually CopyRectToScreen() could be replaced by LockRect(rect,  
> > kWriteOnly);
> > 4) Unification of dirty rectangles calculation in all backends, as  
> > we have full-access to pixel data without full screen invalidation.
> OK, that's already much clearer, and now that you explained the goals  
> (instead of just the solutions to unclear goals :), it's possible to  
> discuss this :).
> One major issue with this is that it seems like a major task which  
> requires lots of changes to all engines and backends, i.e. requires a  
> major coordinated effort. In principle, this is doable, but before  
> even thinking about it further, I wonder what the actual benefit are...
> You explained the theoretical benefits (and I like them ;), but what  
> real-world issues are solved by this? Like, can you name some specific  
> specific combinations of devices and games which currently have issues  
> which cannot be resolved in the current OSystem design, or which are  
> hard to solve with it; and which would become "easy" to resolve with a  
> hypothetical revised API as you propose it ?
> You named engines which might benefit from a colorkey enabled blitting  
> API, etc., but it is not clear to me whether any of those actually has  
> issues which the new API would resolve.
> Note that some engines do full screen updates because their engines do  
> no dirty rect tracking at all, and rewriting those engines to  
> implement dirty rect tracking seems about as complicated as modifying  
> them to use the new API -- so the gain of the new API is not  
> immediately clear to me. And other engines use palette cycling, which  
> forces fullscreen updates anyway.
> Cheers,
> Max
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel




More information about the Scummvm-devel mailing list