Merge pull request #13351 from hrydgard/virtual-framebuffer-format

Virtual framebuffer copies: Make a more informed guess on the pixel format of the copy.
This commit is contained in:
Unknown W. Brackets 2020-08-29 10:06:01 -04:00 committed by GitHub
commit 5945642982
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -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);
}