[Discussion] 60FPS patches for PSP games that run at 30FPS

[Lycanphoenix]

Has anyone figured out how to permanently patch an .ISO with a CWCheat, such as the 60 FPS hack? When I try to use CWCheat on WipEout Pulse or WipEout Pure (unmodified .ISOs), it just causes a crash, and the cheats won't even register on .CSO. WipEout Pulse runs at 60 FPS in all modes except the menu, unlike WipEout Pure, and it has a more sophisticated shader model, so I know it isn't a limitation of the hardware (a real PSP, overclocked to 333/111 Megahertz).

Furthermore, any modification of the .ISO will just makes the cheats that much harder to use, which means if I want to add extra content to Pure (I'm trying to force the exclusive Japanese and American DLC into the European version), I'll have to find a whole new 60 FPS cheat, unless I'm able to patch the individual files BEFORE making the modifications.

(01-06-2016 03:22 AM)[Unknown] Wrote:  Well, forcing games to run at 32-bit color on a real PSP may be a feat, unfortunately.

The PSP had 2MB of VRAM, or in other words 2048KB.

A 16-bit color buffer requires 272KB. But a 32-bit one requires 544KB. Additionally, you essentially must double buffer on the PSP, meaning you need two of those buffers. So it's actually 555KB vs 1088KB.

Even more, most games will require a depth buffer to render properly at all. That costs another 272KB.

So you can see that with 32-bit color, you're quickly left with only 2048MB (VRAM) - 272KB (depth) - 1088KB (colors) = 688KB of remaining VRAM.

But you say, "it fits, doesn't it? Is that a problem?" But this VRAM has to be used for other things:

* Textures
* CLUTs
* Other buffers (to create bloom effects, or shadows, etc.)

So many games may have chosen 32-bit color simply due to free space, not even because of bandwidth. You basically double your remaining VRAM by using 16-bit colors, allowing you to do a lot more other effects. So it may have become a decision of more vibrant colors or better shadows, for example.

That being said, it's theoretically possible to relocate textures and CLUTs to regular RAM. There may be a performance penalty, but it might be livable. However, this would definitely mean non-trivial changes to the game's code. So that's why I say it might be an undertaking.

In PPSSPP, we represent the color buffers on your modern device, that might even have > 1GB of VRAM. So 32 bit color, or even double the resolution, is not really a problem to fit in there. We don't have to be limited by the VRAM the PSP had.

-[Unknown]

Would it be possible to set it to "24-Bit" instead of 16 or 32, as a sort of compromise? And by that, I don't mean the standard "24-Bit PNG" type of 24-Bit color with 8 bits per R-G-B channel, but instead only 6 bits per R-G-B-A channel. I don't know if that would actually work, though. (64 colors per channel, for a total of 262,144 colors with 64 levels of transparency).
EDIT: Alternatively, a 20-Bit color space (RGB 565/666* + 4-bit Alpha, and/or RGBA-5555**) might work.
*Same trick used by the Neo Geo, where the lowest bit is shared across all three color channels. No more precision, but slightly greater vibrancy.
**5 bits per RGBA channel, or 32,768 colors with 32 levels of transparency.

On a slightly related note... how much graphics memory would it save if the resolution was reduced from 480 * 272 to 480 * 270? Those extra 2 pixels of height don't do much of anything, and make upscaling to 1080p/2160p slightly more difficult because of the non-standard aspect ratio (it would be 1088p and 2172p, not very pretty). By reducing the size of the image by a total of 960 pixels, that should save some VRAM, shouldn't it? (Not to mention the slightly smaller screenshots saving a lot of space on the Memory Stick in the long-run).
EDIT: After some calculations, shaving off those 960 unnecessary pixels (you can't cram very much information into just two extra pixels of height) will save, at minimum, 1.8 Kilobytes of VRAM in 16-bit color, or at least 3.6 Kilobytes of VRAM in 32-bit color. Death to the useless pixels.