Difference between revisions of "TODO"

Jump to navigation Jump to search
571 bytes removed ,  22:42, 22 April 2009
→‎SDL backend: we have an rollback system for gfx transactions for some time now, thus remove it from TODO
m (→‎Engines / frontends: Added link to SCI TODO)
(→‎SDL backend: we have an rollback system for gfx transactions for some time now, thus remove it from TODO)
Line 199: Line 199:
=== SDL backend ===
=== SDL backend ===
* Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. They both overload a lot of methods (mostly the graphics stuff). Since graphics.cpp uses the scalers (e.g. hq3x), these derived backends carry that baggage around, too, even though they don't need that code. Idea: split the SDL backend into two classes, one base class which only has the code which is used by all subclasses; and a "desktop" subclass, which implements the rest. Then WinCE/Symbian would only subclass the "base" SDL class.
* Right now, the WinCE and the Symbian backend subclasses the regular SDL backend. They both overload a lot of methods (mostly the graphics stuff). Since graphics.cpp uses the scalers (e.g. hq3x), these derived backends carry that baggage around, too, even though they don't need that code. Idea: split the SDL backend into two classes, one base class which only has the code which is used by all subclasses; and a "desktop" subclass, which implements the rest. Then WinCE/Symbian would only subclass the "base" SDL class.
* We implemented GFX transactions & commits some time ago -- but they are only half the story. We are still missing a rollback system -- that is, check whether the requested video mode works, if it doesn't, revert to the current settings -- at least "if it makes sense". That is, if the transaction only modified the scaler or aspect ratio, we can safely revert. Of course if the screen size changed (e.g. from 320x200 -> 640x480) we can't just revert to the old screen size -- unless we augment the API accordingly, and update all engines to deal with this possibility.
* The <tt>kFeatureAutoComputeDirtyRects</tt> feature is not entirely reliable, and perhaps it cannot ever be. It is currently known to cause glitches in [[AGOS/TODO|The Feeble Files]].
* The <tt>kFeatureAutoComputeDirtyRects</tt> feature is not entirely reliable, and perhaps it cannot ever be. It is currently known to cause glitches in [[AGOS/TODO|The Feeble Files]].


561

edits

Navigation menu