{"id":13,"date":"2013-07-14T19:24:49","date_gmt":"2013-07-14T19:24:49","guid":{"rendered":"https:\/\/blogs.scummvm.org\/rundfunk\/?p=13"},"modified":"2022-05-21T19:26:02","modified_gmt":"2022-05-21T19:26:02","slug":"switching","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/rundfunk\/2013\/07\/14\/switching\/","title":{"rendered":"Switching!"},"content":{"rendered":"

Hi everyone!\u00a0\":)\"<\/p>\n

Now when the switching between the 16-bit and 32-bit mode in the GUI is almost done, I\u2019m going to write a longer blog post detailing the design, decision and implementation of the feature.<\/p>\n

Some background: In the scummvm-master branch, the SDL-renderer for the GUI has a hardcoded bit-depth of 16-bits in some places. My intention has been to \u201cun-hardcode\u201d this, replacing the constants into variables that depend on the bit-depth set, so that arbitrary bit-depths can be used (although the code is focusing on 32-bits right now). The difference between 16 and 32 bits in the GUI can, as an example, be seen in the picture below, with the 32-bit rendering giving a nicer gradient, especially on the buttons \u2013 without having to resort to dithering:<\/p>\n

\"32\"(Editor\u2019s note: unfortunately, the image that was included here is lost and not available on archive.org)<\/a><\/p>\n

One of the problems one runs into with switching to a 32-bit surface is that it does break games and scalers used, which assume a 16-bit surface is being used. To remedy this problem, my current solution involves switch back to a supported 16-bit format (using a new function setScreenFormat) when running a game from the launcher, and then switching back to the old 32-bit format used (using the new function setOverlayFormat) if the player enters a menu while playing, or re-enters the launcher.<\/p>\n

This solution seems to work pretty fine, and only a couple of things need fixing now:<\/p>\n