Ppsspp darkstalkers on android

[[Unknown]]

Well, that's why we have a software renderer - to emulate the way any game might draw. It still has bugs, but the biggest problem is that it's slow. I've actually spent a bunch of time making it faster (and it has gotten faster), and I have some plans still to improve it more.

But like I said, modern GPUs and designed for the way modern graphics are drawn. There are many things one can do with the PSP's GPU that are actually faster (even on that 333 Mhz device and its 167 Mhz GPU) than on a modern device - in part because the PSP didn't have drivers blocking you from accessing the GPU directly. Vulkan has helped here in some ways (it gives us more low level access to the GPU), but it's still not able to change the situation entirely.

To get specific about the problems with the "read framebuffers to memory" option - part of the trouble is that the PSP GPU just draws directly to video memory. Modern graphics are drawn to a "surface" that has dimensions. So if I tell the GPU to draw, I need to first decide the width and height of the surface.

That's fine really, but the problem comes in when you download that to RAM. "Read framebuffers to memory" guessed that whatever random height we made up was a useful number, and deleted any RAM in that area. Sometimes, this was fine. Often, it was not - we might've created a 512x512 surface but the game was only drawing a tiny shadow and the VRAM/RAM later was important. At best, this would cause glitches and missing textures, and worst it would cause crashes.

The new strategy is to find the right places where games actually transfer memory. The benefit of this is that they give us a size - even if they are copying 1024 bytes, that gives us a safe number to work in to guess the width and height.

The majority of games use a memory copy or block transfer operation to do these transfers, but some games do little effects pixel-by-pixel (as I mentioned, games generally don't draw this way but some games use it for certain special effects.) In those cases, we've resorted to applying a hook that detects the special effect code and the size of the memory it's working on to apply the transfer.

It's a bit hacky, unfortunately, but it's really the only way to tie in the hardware usage. If you've got other ideas on ways to do it (that aren't just corrupting vast amounts of RAM willy-nilly), I'm definitely all ears. Of course, these hooks do nothing when using software rendering - that is more faithful and compatible, albeit slow.

Note again that even this block transfer comes at a cost, but so far we've been able to get better performance by doing the above too, since "read framebuffers to memory" really did transfers way too often, in addition to doing them at the wrong size.

A way you could help is to investigate the game using the debugger to try to find where and how it applies the effect. If we can find the function in the game that directly messes with the VRAM, and find somewhere in it we can detect the range it's modifying, we may be able to apply a hook. In this case, it'd probably be pretty game specific (and again, that's unfortunate) but it could be enough to make the game work in the hardware renderers.

-[Unknown]