[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