Framebuffer emulation needs to be cropped when Adjust game to fit is enabled.

[blackhand1001]

OS: Windows 10 22H2 Version: GlideN64 rev 2973f53, Project 64 dev 3.0.1.5670-400f110 Game: Banjo Kazooie (U) 1.0

When Adjust game to fit is enabled the framebuffer is captured as if it was 16:9 but it only can be outputted as 4:3 leading it to be squished or worse having white borders arounds on the sides. If this could be corrected we could have nearly perfect Banjo Kazooie widescreen by just enabling the two culling codes and not touching the internal aspect ratio code which unfortunately messes up the hud.

The only things broken right now are the pause screen and the puzzle piece effect both of which expect a 4:3 framebuffer. If we could just crop out the sides it would work perfectly. The pause menu would just only fill the 4:3 area with black borders on the sides.

Here is how it currently works. You can test this by enabling Adjust game to fit and turning on the following two gameshark codes to adjust the games ingame culling.

Widescreen Culling 81277A0C 4334 81277A10 4334

Unpaused:

Paused:

Render N64 Framebuffer to output enabled to show that the framebuffer is being squished:

If this could be fixed I imagine this could enable working widescreen modes for a great number of games that don't have properly working ones or end up misaligning the HUD.

[gonetz]

The only things broken right now are the pause screen and the puzzle piece effect both of which expect a 4:3 framebuffer.

~Could you give me a savestate for the puzzle piece effect?~

Sorry, I need a save not for the puzzle piece effect, which happens when we switch a level, but for solving Puzzles, when we need to solve a puzzle for a limited time.

[gonetz]

An explanation of the problems. As you know, widescreen is a hack. Plugin changes x coordinate of 3D objects to place more objects between clipping planes. These 3D objects would look shrunk with 4:3 viewport, but they look correct with the extended viewport. The viewport extends not only 3D objects, but 2D texrects as well. It it not what we want, so the plugin corrects coordinates of texrects, so they have normal size on screen. The exception is done for screen-width texrects, which are usually used to draw backgrounds. We don't have wide version of 2D backgrounds, so the plugin extends background textures to avoid black boarders. Many games use frame buffer as a background texture for pause screen. Most of them draw that background by splitting the large image on narrow screen-width strips. The plugin extends these textures when wide-screen is enabled. However, both Banjo games draw the pause screen background using 64x32 tiles. The plugin treats such tiles as a normal 2D texrects, which should not be extended. Thus we have shrunk background image. This problem can easily be fixed. Another hack technique can help as - hardware frame buffer emulation. HWBE uses hi-res video card's frame buffer texture instead of low-res frame buffer from RDRAM for frame buffer effects. It works for pause-screen background image too. Thanks to it you don't see quality downgrade when you open a pause screen. We can check if a texrect uses frame-buffer texture, and don't shrink it if it does. I don't remember texrects, which use frame buffer texture for anything else but background, so it should not lead to regression. I created PR with that fix: #2773

Unfortunately, the second issue, "puzzle piece effect", hardly can be solved. This effect does not use texrects at all. Everything is rendered with 3D triangles: When widescreen is enabled, we see more of these triangles, but additional triangles have no additional 2D image, so they wrap original 4:3 image. HWBE does not help us there because this effect can't be emulated with HWBE.

[Xii-Nyth]

Note: this is very "out there"

I know of a video plugin (True Reality 64) which can dump the 3d objects drawn on the screen to a .obj file.

If you were able to isolate the puzzle pieces from the other 3d objects on screen (perhaps there is something unique about them which can be used to identfy them?), you could in theory dump them and remove them from the scene, and then put them back in place with a function to resize them.

[gonetz]

PR https://github.com/gonetz/GLideN64/pull/2773 is merged, that's all I can do for that task. Closed.

[gonetz]

If you were able to isolate the puzzle pieces from the other 3d objects on screen (perhaps there is something unique about them which can be used to identfy them?), you could in theory dump them and remove them from the scene, and then put them back in place with a function to resize them.

Sounds as a crazy hack.