From 8618cc7ab5f793475275554b2a3dd020717822ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Henrik=20Rydg=C3=A5rd?= Date: Sat, 29 Aug 2020 12:42:36 +0200 Subject: [PATCH] Virtual framebuffer copies: Make a more informed guess on appropriate pixel format. This is the first part of the Test Drive fix, which I want in separately. --- GPU/Common/FramebufferManagerCommon.cpp | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/GPU/Common/FramebufferManagerCommon.cpp b/GPU/Common/FramebufferManagerCommon.cpp index 3b49bad205..ab95f7de01 100644 --- a/GPU/Common/FramebufferManagerCommon.cpp +++ b/GPU/Common/FramebufferManagerCommon.cpp @@ -1293,9 +1293,19 @@ void FramebufferManagerCommon::FindTransferFramebuffers(VirtualFramebuffer *&dst } if (!dstBuffer && PSP_CoreParameter().compat.flags().BlockTransferAllowCreateFB) { - GEBufferFormat ramFormat = bpp == 4 ? GE_FORMAT_8888 : GE_FORMAT_5551; - // TODO: We don't really know the 16-bit format here.. at all. Can only guess when it gets used later! - // But actually, the format of the source buffer is probably not a bad guess.. + GEBufferFormat ramFormat; + // Try to guess the appropriate format. We only know the bpp from the block transfer command (16 or 32 bit). + if (bpp == 4) { + // Only one possibility unless it's doing split pixel tricks (which we could detect through stride maybe). + ramFormat = GE_FORMAT_8888; + } else if (srcBuffer->format != GE_FORMAT_8888) { + // We guess that the game will interpret the data the same as it was in the source of the copy. + // Seems like a likely good guess, and works in Test Drive Unlimited. + ramFormat = srcBuffer->format; + } else { + // No info left - just fall back to something. But this is definitely split pixel tricks. + ramFormat = GE_FORMAT_5551; + } dstBuffer = CreateRAMFramebuffer(dstBasePtr, dstWidth, dstHeight, dstStride, ramFormat); }