mirror of
https://github.com/hrydgard/ppsspp.git
synced 2025-04-02 11:01:50 -04:00
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:
commit
5945642982
1 changed files with 13 additions and 3 deletions
|
@ -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);
|
||||
}
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue