Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
from

Conversation

@BallM4788
Copy link
Contributor

BallM4788 commented Nov 10, 2019

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

This comment has been minimized.

Copy link
Member

bgK commented Nov 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

BallM4788 commented Nov 13, 2019

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

This comment has been minimized.

Copy link
Member

bgK commented Nov 13, 2019

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

This comment has been minimized.

Copy link
Contributor Author

BallM4788 commented Nov 19, 2019

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.

…mats

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.
@BallM4788 BallM4788 force-pushed the BallM4788:3ds_rivenpostmagfixes branch from 179d711 to a6ea4fc Nov 26, 2019
@BallM4788 BallM4788 changed the title MOHAWK: RIVEN: For running full-speed on 3DS, add preprocessor macro defs and conditional inclusions MOHAWK: RIVEN: Allow for running in either 16-bit or 32-bit pixel formats Nov 26, 2019
@BallM4788

This comment has been minimized.

Copy link
Contributor Author

BallM4788 commented Nov 26, 2019

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.

@BallM4788 BallM4788 closed this Dec 2, 2019
@sev-

This comment has been minimized.

Copy link
Member

sev- commented Dec 2, 2019

Why did you close it?

@BallM4788 BallM4788 reopened this Dec 2, 2019
@BallM4788

This comment has been minimized.

Copy link
Contributor Author

BallM4788 commented Dec 2, 2019

Oops.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.