[Scummvm-cvs-logs] scummvm master -> 51466ecfbb8158792931c27ff00c3bf937adfd40

lordhoto lordhoto at gmail.com
Wed Jun 13 05:11:12 CEST 2012


This automated email contains information about 3 new commits which have been
pushed to the 'scummvm' repo located at https://github.com/scummvm/scummvm .

Summary:
d99eb1e614 COMMON: Remove last traces of 8bpp overlay support from OSystem docs.
09ea48978a COMMON: Remove traces of overlay scale from the OSystem documentation.
51466ecfbb COMMON: Remove traces of mouse cursor target scale from OSystem docs.


Commit: d99eb1e6141ba6dc33ca9f600267d4787a67db48
    https://github.com/scummvm/scummvm/commit/d99eb1e6141ba6dc33ca9f600267d4787a67db48
Author: Johannes Schickel (lordhoto at scummvm.org)
Date: 2012-06-12T19:57:55-07:00

Commit Message:
COMMON: Remove last traces of 8bpp overlay support from OSystem docs.

Changed paths:
    common/system.h



diff --git a/common/system.h b/common/system.h
index 976a3d2..60c0e0f 100644
--- a/common/system.h
+++ b/common/system.h
@@ -389,10 +389,7 @@ public:
 	 * graphics have a resolution of 320x200; then the overlay shall
 	 * have a resolution of 640x400, but it still has the same
 	 * physical size as the game graphics.
-	 * The overlay usually uses 16bpp, but on some ports, only 8bpp
-	 * are availble, so that is supported, too, via a compile time
-	 * switch (see also the OverlayColor typedef in scummsys.h).
-	 *
+	 * The overlay is forced to a 16bpp mode right now.
 	 *
 	 * Finally, there is the mouse layer. This layer doesn't have to
 	 * actually exist within the backend -- it all depends on how a
@@ -758,13 +755,11 @@ public:
 	 * In order to be able to display dialogs atop the game graphics, backends
 	 * must provide an overlay mode.
 	 *
-	 * The overlay can be 8 or 16 bpp. Depending on which it is, OverlayColor
-	 * is 8 or 16 bit.
+	 * The overlay is currently forced at 16 bpp.
 	 *
 	 * For 'coolness' we usually want to have an overlay which is blended over
 	 * the game graphics. On backends which support alpha blending, this is
-	 * no issue; but on other systems (in particular those which only support
-	 * 8bpp), this needs some trickery.
+	 * no issue; but on other systems this needs some trickery.
 	 *
 	 * Essentially, we fake (alpha) blending on these systems by copying the
 	 * current game graphics into the overlay buffer when activating the overlay,


Commit: 09ea48978a80e5148be74a7a5ffb2ff099e74ad7
    https://github.com/scummvm/scummvm/commit/09ea48978a80e5148be74a7a5ffb2ff099e74ad7
Author: Johannes Schickel (lordhoto at scummvm.org)
Date: 2012-06-12T20:06:58-07:00

Commit Message:
COMMON: Remove traces of overlay scale from the OSystem documentation.

Changed paths:
    common/system.h



diff --git a/common/system.h b/common/system.h
index 60c0e0f..9720584 100644
--- a/common/system.h
+++ b/common/system.h
@@ -380,15 +380,15 @@ public:
 	 *
 	 *
 	 * The next layer is the overlay. It is composed over the game
-	 * graphics. By default, it has exactly the same size and
-	 * resolution as the game graphics. However, client code can
-	 * specify an overlay scale (as an additional parameter to
-	 * initSize()). This is meant to increase the resolution of the
-	 * overlay while keeping its size the same as that of the game
-	 * graphics. For example, if the overlay scale is 2, and the game
-	 * graphics have a resolution of 320x200; then the overlay shall
-	 * have a resolution of 640x400, but it still has the same
-	 * physical size as the game graphics.
+	 * graphics. Historically the overlay size had always been a
+	 * multiple of the game resolution, for example when the game
+	 * resolution was 320x200 and the user selected a 2x scaler and did
+	 * not enable aspect ratio correction it had a size of 640x400.
+	 * An exception was the aspect ratio correction, which did allow
+	 * for non multiples of the vertical resolution of the game screen.
+	 * Nowadays the overlay size does not need to have any relation to
+	 * the game resolution though, for example the overlay resolution
+	 * might be the same as the physical screen resolution.
 	 * The overlay is forced to a 16bpp mode right now.
 	 *
 	 * Finally, there is the mouse layer. This layer doesn't have to


Commit: 51466ecfbb8158792931c27ff00c3bf937adfd40
    https://github.com/scummvm/scummvm/commit/51466ecfbb8158792931c27ff00c3bf937adfd40
Author: Johannes Schickel (lordhoto at scummvm.org)
Date: 2012-06-12T20:09:02-07:00

Commit Message:
COMMON: Remove traces of mouse cursor target scale from OSystem docs.

Changed paths:
    common/system.h



diff --git a/common/system.h b/common/system.h
index 9720584..94bf7f0 100644
--- a/common/system.h
+++ b/common/system.h
@@ -396,14 +396,6 @@ public:
 	 * backend chooses to implement mouse cursors, but in the default
 	 * SDL backend, it really is a separate layer. The mouse can
 	 * have a palette of its own, if the backend supports it.
-	 * The scale of the mouse cursor is called 'cursorTargetScale'.
-	 * This is meant as a hint to the backend. For example, let us
-	 * assume the overlay is not visible, and the game graphics are
-	 * displayed using a 2x scaler. If a mouse cursor with a
-	 * cursorTargetScale of 1 is set, then it should be scaled by
-	 * factor 2x, too, just like the game graphics. But if it has a
-	 * cursorTargetScale of 2, then it shouldn't be scaled again by
-	 * the game graphics scaler.
 	 *
 	 * On a note for OSystem users here. We do not require our graphics
 	 * to be thread safe and in fact most/all backends using OpenGL are






More information about the Scummvm-git-logs mailing list