MOHAWK: RIVEN: Allow for running in either 16-bit or 32-bit pixel formats

[BallM4788]

On the 3DS, video playback and all visual effects for Riven are slow due to constant pixel format conversion; Riven's engine is currently hardcoded to use RGB565, while the 3DS backend uses RGBA8888 throughout. This pull request adds several preprocessing directives which allow for the Riven engine to run in 8888 on 3DS builds of ScummVM, but remain in 565 on all other platforms.

Important Notes:

• The WIDTHMULTI macro is necessary for 3DS builds because, without it, implementing an 8888 format causes the blend transition effect to occur only on the left half of the screen(s).
• In 3DS builds, the pixel format MUST be pulled from the 3DS backend's list of supported formats (i.e. not created with Graphics::createPixelFormat), or else video playback and visual effects will remain slow.

[bgK]

Did you measure the time that is actually spent doing the color conversion in the 3DS backend?

Otherwise:

• We generally don't write platform-specific code in the game engines. So, changing the 3DS backend to natively support the 565 pixel format would be better (I did it as a test a while back but the performance gains did not justify the code complexity). Or alternatively changing the Riven engine to adapt according to the preferred backend pixel format. The former would be better as it would help other engines.
• There are other places in the Riven engine that assume the pixel format is 16bits.

[BallM4788]

I got a new branch going on here for working on converting the 3DS backend to RGB565. So far, everything seems to work except for the lack of transparency on the cursor and the menu overlay (obviously due to the absence of an alpha byte). Right now I'm thinking about how to get around that.

[bgK]

I got a new branch going on here for working on converting the 3DS backend to RGB565. So far, everything seems to work except for the lack of transparency on the cursor and the menu overlay (obviously due to the absence of an alpha byte). Right now I'm thinking about how to get around that.

Maybe keeping the screen in a 32 bits pixel format, and simply using the hardware to do the 565 -> 8888 conversion would be a better approach as it would not hurt other games using a 32bit pixel format directly. See this quick hack: bgK@a75c300.

[BallM4788]

I've been looking through the source code for citro3D and libctru trying to formulate a plan of action, and so far it seems to me like the best way to do this is to do the following each time a game is launched based on its preferred color format:

• Change the input and output color format of the _gameTopTexture and _gameBottomTexture Sprites;
• Go in and change the color format of the frame buffer in the C3D_RenderTarget of each screen;
• Change the color formats of the screens themselves with libctru's "gfxSetScreenFormat()".

The primary goal being to keep the number and amount of 16bit-to-32bit / 32bit-to-24bit / etc. conversions per frame during gameplay at an absolute low. For drawing the cursor in games running in alphaless formats (eg RGB565), I might try to borrow from the method the Riven engine uses to color blend the flies effects.

This is just the general gameplan at the moment. I'm still working on the specifics, but I'm almost certain that this is all doable.

[BallM4788]

I need to understand the workings of libctru and citro3d more before I can proceed with my above plan. In the meantime, I've changed this pull request from it's original proposal (adding preprocessor macro defs and conditional inclusions for improved performance on the 3DS specifically) to the less-specialized proposal of allowing for Riven to run in either 16-bit or 32-bit pixel formats. No preprocessing like in the original pull request.

Here is the new summary:

If platform has a list of supported formats, refer directly to the most
preferred format on the list instead of using Graphics::PixelFormat or
Graphics::createPixelFormat to replicate the format. This helps to reduce
or even prevent video and effects slowdown on lower-power platforms such
as the 3DS.

I have tested this on the 3DS, and to my knowledge everything is running properly in RGBA8888, including the flies/fireflies effect; that last one is one I had missed before. Please let me know if further modifications need to be made.

[sev-]

Why did you close it?

[BallM4788]

Oops.