Historically, the OSystem API used to have a method which allowed creating threads. Hence mutex support was needed for thread syncing. To ease portability, though, we decided to remove the threading API. Instead, we now use timers (see setTimerCallback() and Common::Timer). But since those may be implemented using threads (and in fact, that's how our primary backend, the SDL one, does it on many systems), we still have to do mutex syncing in our timer callbacks. In addition, the sound mixer uses a mutex in case the backend runs it from a dedicated thread (as e.g. the SDL backend does).

Hence backends which do not use threads to implement the timers simply can use dummy implementations for these methods.

Static Private Attributes

Graphics

The way graphics work in the class OSystem are meant to make it possible for game frontends to implement all they need in an efficient manner. The downside of this is that it may be rather complicated for backend authors to fully understand and implement the semantics of the OSystem interface.

The graphics visible to the user in the end are actually composed in three layers: the game graphics, the overlay graphics, and the mouse.

First, there are the game graphics. The methods in this section deal with them exclusively. In particular, the size of the game graphics is defined by a call to initSize(), and copyRectToScreen() blits the data in the current pixel format into the game layer. Let W and H denote the width and height of the game graphics.

Before the user sees these graphics, the backend may apply some transformations to it; for example, the may be scaled to better fit on the visible screen; or aspect ratio correction may be performed (see kFeatureAspectRatioCorrection). As a result of this, a pixel of the game graphics may occupy a region bigger than a single pixel on the screen. We define p_w and p_h to be the width resp. height of a game pixel on the screen.

In addition, there is a vertical "shake offset" (as defined by setShakePos) which is used in some games to provide a shaking effect. Note that shaking is applied to all three layers, i.e. also to the overlay and the mouse. We denote the shake offset by S.

Putting this together, a pixel (x,y) of the game graphics is transformed to a rectangle of height p_h and width p_w appearing at position (p_w * x, p_hw * (y + S)) on the real screen (in addition, a backend may choose to offset everything, e.g. to center the graphics on the screen).

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. 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).

Finally, there is the mouse layer. This layer doesn't have to actually exist within the backend -- it all depends on how a 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.