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

[Vladimir Menshakov]

10.11.09, 16:54, "Max Horn" :

> 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? 
We avoiding fullscreen updates which could be painful in case of embedded development. 
No modification of existing code are urgently needed. It could be delayed for any time. 
 
> 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 ?
Why hypothetical? It is widely used. Direct3d for example. 
> 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.
Please grep scummvm sources by "lockScreen". In most cases lockScreen is localized in rectangle and do not requires any fullscreen update. 

> 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.
No modification needed to the existing engines. Locking rectangle is just a generalization of the old api. 
LockScreen() equals LockRect(320x200, kRead | kWrite);
CopyRectToScreen(rect) remains in backends as optimized and maybe hardware-accelerated quick memory copy into screen. 
LockRect(rect, kWrite) equals to CopyRectToScreen.
> 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