|
|
| Line 126: |
Line 126: |
|
| |
|
| * Reasonable C++ skills. | | * Reasonable C++ skills. |
| * Refactoring skills.
| |
| * Knowledge of one or more ScummVM platform backends is desirable.
| |
|
| |
| === Improve the overlay API ===
| |
| ''Technical Contact'': [[User:Fingolfin|Max Horn]]
| |
|
| |
| ''Background:''
| |
|
| |
| ScummVM is a highly portable application, running on a multitude of devices, ranging from desktop PCs running Linux, Mac OS X, Windows and other systems, over game consoles like the PlayStation or the Nintendo DS, down to small mobile devices like PDAs and smartphones running PalmOS, WinCE or Symbian. One key component which makes this possible is our relatively strict separation between "backend code" (which implements the device specific functionality, like graphics drawing or sound output), and "frontend code" (which implements support for certain games). These two parts are held together by a bit of middle layer code. The key API for all backends is the [http://doxygen.scummvm.org/d9/df4/classOSystem.html OSystem class] (you can use it as a great starting point to figure out most of the rest of the backend API).
| |
|
| |
| Two key components of the backend API are the game graphics (used for drawing the game graphics, surprise surprise), which are currently limited to 8bit palette mode, and the overlay graphics (used to e.g. draw the GUI, and currently either 16bit or 8bit palette, fixed at compile time). For the overlay API, it would be nice if we could support arbitrary graphics modes, e.g. also 24/32bit modes.
| |
|
| |
| The current overlay API is rather inflexible when it comes to supporting different modes. Most code assumes that the overlay is in 16 bit mode. For 8bit mode, a compile time switch has to be used, and supporting 24/32bit mode is virtually impossible. Furthermore, which variant of 16bit mode is determined through an ugly global variable <code>gBitFormat</code> (set by the InitScalers() function in <code>graphics/scaler.cpp</code>): This variable is set to values like 555, 565 to indicate the 16bit mode variant (555 meaning that 5 bits are used for each color component, while 565 means 5bits for red, 6 for green, 5 for blue). Some systems use other modes, like 1555, 4444, or even use BGR instead of RGB. For 32bit modes, things are even more complicated.
| |
|
| |
| ''The Task:''
| |
|
| |
| Get rid of the evil gBitFormat variable. Instead, introduce a new Graphics::PixelFormat struct (modeled after [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat]). Enhance Graphics::Surface to use it (similar to [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSurface SDL_Surface]). Add a new getOverlayPixelFormat method to OSystem, and implement it in the SDL backend. Rewrite the GUI code and other code accessing the overlay to make use of the PixelFormat data, instead of using gBitFormat. This also includes updating some of the scalers (at least the simple ones; for the special ones, like HQ2x, we have to determine how to treat them best).
| |
|
| |
| For all this, API flexibility has to be carefully weight against API complexity, and efficiency -- since we have to support small devices with limited resources, we don't want to needlessly waste CPU cycles nor memory.
| |
|
| |
| Also, the PixelFormat code and its usage have to be documented (using Doxygen comments, and maybe a concept document), as our porters will have to implement these changes, and it must be as clear and easy as possible for them to do so.
| |
|
| |
| ''Required Skills:''
| |
|
| |
| * Good C++ skills.
| |
| * Refactoring skills. | | * Refactoring skills. |
| * Knowledge of one or more ScummVM platform backends is desirable. | | * Knowledge of one or more ScummVM platform backends is desirable. |