1.17 is out!

 

PPSSPP 1.17 - release announcement and progress report

PPSSPP 1.17 is now out! Get it on the download page! If you're on Android and already have it installed from Google Play, your update will arrive within a week (to catch crashes early).

For fine details, see the news item.

Download now!

Beta program

For the first time, you can now sign up to receive beta versions automatically. This is easier and safer than installing APKs from the buildbot, and you make a valuable contribution to development. See details here.

CHD support

CHD was originally a format for compressing hard drives from arcade games in MAME, but has since became the most popular format for storing ISOs for CD- and DVD-based video game consoles. PSP already has a different format, CSO, which can be used to similarly loss-lessly compress ISOs, and as a bonus, unlike CHD, these actually work on the real hardware.

So you might ask, why support CHD? It does provide a slightly better compression ratio, but the main reason is that it's simply been requested a lot. Many people seem to familiarize themselves with a set of tools, and since CHD works to compress ISOs for most other systems, people just want to stick with it. So now we support it.

IMPORTANT! You MUST use the createdvd command from recent versions of chdman to generate your CHDs. createcd will work but there will be severe performance problems. See issue #18798.

Example command line:

chdman createdvd -i "Grand Theft Auto - Vice City Stories.ISO" -o GTA_VCS_dvd.chd

Important fixes in 1.17

  • Several serious hangs and crashes that could happen when switching away from the app, especially from the pause screen, have been fixed.
  • Multiple rendering issues have been fixed, and rendering performance has been further optimized.
  • PPSSPP now tracks total time played per game, you can check it in the info screen for each game (long press the icon).
  • Some new UI features, like the ability to keep the game running behind the pause menu overlay.
  • Many input fixes, especially around deadzone handling for both analog stick and tilt control.
  • Many bugfixes around texture replacement.
  • Input latency has been greatly improved on the SDL build with Vulkan. Don't use OpenGL on Linux if you can avoid it.
  • For RetroAchievements, renamed the Challenge mode to Hardcore mode and made it the default, as is standard.

For a more detailed changelog, see the release notes.

1.16 release

 

PPSSPP 1.16 - release announcement and progress report

PPSSPP 1.16 is now out! Get it on the download page!

PPSSPP 1.16.1-6 were also released, with some important hang and crash fixes.

For fine details, see the news item.

RetroAchievements support

RetroAchievements is a long-running project to add "achievements", similar to Xbox Achievements or Playstation Trophies, to game for old video game consoles, in order to add extra challenges and improve replayability, and also making the whole experience feel a bit more modern.

In 1.16, PPSSPP adds full support for RetroAchievements. On the System tab in settings, you can now click RetroAchievements to reach a dialog where you can log in to your RA account. You can't register the account directly from within PPSSPP though, as it's an external service.

RetroAchievements has a very passionate community and is getting more and more popular. Unfortunately, achievement definitions are not yet available for all games, and on the PSP they're often only available for a single regional version of a game, so watch out for that if you want to try it. To check, on the RetroAchievements website when browsing games, you can check the "Supported Game Files" link on a game's page to see which UMD you'll need to acquire and dump.

Important fixes in 1.16

  • A lot of people on Android 13 devices ended up in a situation where the choose-a-folder dialog during set up didn't work correctly. This has been fixed.
  • Multiple input event handling fixes, should help with external joysticks
  • Perf improvements on lower end devices by disabling ubershaders
  • Multiple fixes for glitches like flicker in WWE vs Smackdown 2006, shadows in Motorstorm, etc.
  • Lots of additional performance improvements and fixes
  • Multiple bugfixes around texture replacement, fixing Tactics Ogre fonts among other things

New JIT backends by [Unknown]

A background development that most people won't notice yet, but will have long-term performance benefits in addition to compatibility with more CPU architectures, is the addition of new IR-based JIT compiler backends.

PPSSPP has long supported recompiling the PSP's MIPS code to an easier-to-interpret intermediate representation which we call IR, in order to speed up platforms where we can't always JIT-compile like iOS. This IR is not only easier for the CPU to interpret than raw MIPS instructions, but can also easily be processed through optimization passes, which can thus be general across architectures.

We've long had a plan to eventually try to compile the IR to native code, which would gain the benefit of general optimization passes, while still producing really fast native code. When starting his RISC-V backend, [Unknown] chose to use this approach, and then proceeded to write x86/x86-64 and ARM64 backends, too. Currently, these are at parity or a bit faster than the existing JITs, but much less tested which is why they're not yet selectable in the UI.

Correct emulation of vrnd by fp64

fp64 has been working on trying to reverse engineer accurate implementations of some of the more obscure math instructions of the PSP's VFPU, a custom little SIMD coprocessor. Previously he solved sin/cos/sqrt among others, now the turn came to the vrnd instruction. Surprisingly it seems to consist of a mix of multiple traditional random number generators. Some details can be found in this issue on github.

The 1.15.x release process

 

The 1.15.x release series has been out now for a couple of weeks, including some point-releases. These have been made mostly as direct response to crash reports but also for some other fixes. Time to summarize!

  • Overall crash rate is down by about 20% from previous releases
  • It took three point-releases to get there though! A few new crashes emerged in this release, but I also fixed some old ones while at it.
  • People seem generally happy with the release, but there have been some negative reviews coming in, mostly about slowdown on older devices, control mapping problems, and even about how the new icon is ugly.

Thus, a fourth point-release is rolling out about now, 1.15.4, with the following changes:

  • Some optimizations to claw back most of the lost performance
  • The Android device resolution / HW scaler setting will be back
  • Fixes for running things directly out of the Downloads folder using the Load button on newer Android versions
  • Fixes for some control mapping problems
  • On devices that don't understand the new icon format, use the old icon instead of an ugly auto-generated one.
  • Fix loader bug triggered by WWE 2009, preventing it from starting
  • Tilt control gets back a lost setting (inverse deadzone, or "low end radius")
  • A couple of updates to compat.ini.

Hopefully this will be enough to avoid a fifth!

While looking at performance to eliminate some regressions, I found plenty of additional room for improvements, and I have a bunch of good changes pending. Mostly though, these will need serious testing so I cannot merge them until after we're done with the main series of 1.15.x releases, to keep things simple. But expect serious performance improvements on old devices in 1.16!

Anyway, enjoy!

Progress Report - spring 2023

 

PPSSPP Progress Report - Spring 2023

Welcome to the first official Progress Report! I've long enjoyed reading Dolphin's progress reports, but it turns out to take quite the effort to write one. So, it's not likely that these will be monthly going forward, but either way, here's the first one. More likely these will accompany each official new official release. Essentially, these will be longer form versions of the release notes.

PPSSPP has been an ongoing project for over 11 years now, but work never ends! The new version, 1.15, is another pretty good upgrade. The main themes are stutter fixes and quality-of-life improvements, and obviously some compatibility fixes and performance improvements as usual. Additionally, macOS is now an officially supported platform, and support has been improved substantially.

So go Download PPSSPP 1.15! New: There's now an official Mac build!

Please note that the Android version on Google Play will as usual roll out slowly over multiple days in order to catch any bad crashes early, so you may have to wait a few days before you receive the update.

1.15 - top improvements

Reduction of shader compilation stutter

PPSSPP has long had problems with stutter caused by shader compilation, and it had reached a point where it was stuttering enough to nearly be unplayable initially on some devices with very slow shader compilers, such as devices with the PowerVR GE8320.

Two changes have been made to improve on this: First, the sheer amount of different shader variants was a bit excessive. We'd compile separate shaders for every little shading state bit, such as the double-color-value or fog flags. Now, a bunch of these are controlled by uniform values instead, so the shader count has gone down by as much as half or more in many games. We still have more variants than we really need, but the problem is much smaller now. This change affects all rendering backends.

Additionally, in Vulkan, we now do shader compilation (as in pipeline creation) in parallel on multiple threads, which is a huge improvement on some drivers like the ones for PowerVR GPUs (which are increasingly common in lower-end phones like Galaxy A21), a minor improvement on Adreno and generally neutral on Mali. The devices seeing the biggest improvements were also the slowest before, so definitely worthwhile.

Texture replacement rework

In PPSSPP, you can install "texture replacement packs", containing higher resolution textures for a game. PSP games were made for a low resolution screen.

The texture replacement code has evolved over the years but had some lingering problems, like too much I/O on the main thread. It's now been substantially reorganized and partly rewritten, moving more work to background threads - which reduces stutters caused by loading new replacement textures by quite a bit. Additionally, support for efficient compressed texture formats has been added (KTX2 with Basis and UASTC, DDS with BC1-7), along with built-in mipmap support (#17134, #17092, #12059). Using these can further speed up loading and improve quality while also reducing the memory use.

In connection with this, video memory use when loading large textures to VRAM has been optimized. This mainly helps when using texture replacement packs with very high-resolution textures, but will reduce the risk of running out of memory in general, which is one of the major remaining causes of reported crashes on Android.

Display and post-processing features

Integer scaling can now be enabled. This ensures that the emulated PSP framebuffer is scaled to an even multiple of the rendering resolution. If you then enable "Nearest" filtering, you get nice square pixels, if you're after the retro look.

Additionally, a bug has been fixed where temporary buffers during applications of post filters were the wrong size if we detected oversized framebuffers in games, causing little glitches.

Rendering fixes and features

  • We can now texture-sample from render targets that have been cast to CLUT formats, using a palette that comes from yet another render target. Fixed some special effects: #8390. See the GPU image formats page for more information about the PSP's CLUT functionality and what can be done with it. Additionally, we now support a few additional CLUT texturing modes, which fixes night vision and other effects in the SOCOM games.

  • Xiaomi Poco C40 phones, which are quite widespread in some countries, only expose a software Vulkan device, which is missing some mandatory features. This caused PPSSPP's UI to render incorrectly and slowly, and even worse in-game. I have corrected the Vulkan device detection code to reject this software device - which simply means these phones will fallback to using OpenGL instead, which is reasonably functional on them.

  • Fixed a slowdown in Naruto Heroes: #16733. This is a very typical case of unnecessary readbacks. The PSP has a "block copy" command to copy around arbitrary GPU memory between RAM and VRAM. PPSSPP designates areas in VRAM as framebuffers if they have been previously rendered to, and copies between two framebuffers can be simply converted to a GPU copy on the host. However, if data is copied to "new" VRAM or to RAM, by default we assume that the game will try to read the copied data with the CPU. This means we have to do a very costly readback. Often it actually doesn't need the data on the CPU, though, so we added a per-game compatibility option where we automatically create framebuffers covering the destination area of memory. If the game later simply textures from it, this becomes much, more more efficient than a readback from the GPU. We enabled this for Naruto Heroes.

The curious case of skewed input

It was noticed that Daxter and the two God of War games (all three from the studio Ready At Dawn) both rotate the analog stick input by 15 degrees before passing it to the game's internal control system. This makes the analog stick feel better aligned on the real PSP and likely good for ergonomics, but is not appropriate for an emulator that takes many kinds of different inputs, so automatic pre-rotation in the other direction was added to compensate. Daxter now walks correctly along the cardinal directions as expected, and Kratos does too in the God of War games. See #17020.

Tilt control has been improved

The Android-only tilt (accelerometer) input feature has not been maintained nor tested for a long time, so it was simply time to go through it and fix it up, which is now done. The new behavior works much better and is more intuitive to configure, thanks to an updated configuration dialog.

Regressions fixed

  • Thrillville rendering corrected (#17169)
  • A major performance regression in Dante's Inferno has been fixed (#17032)
  • Mipmaps are now actually used with texture replacement, if provided (#17144)

Other changes

  • Depth readback added, fixing lens flares in Syphon Filter (at a perf cost.. turn off GPU readbacks for the old behavior) (#16907, #16905)
  • Enabling rewind savestates (automatic savestates every N seconds) no longer slow down gameplay noticeably.
  • Software renderer is even more playable, after another round of optimizations and fixes by [Unknown]
  • fp64 has worked on VFPU accuracy. It's not yet all enabled, though.
  • Multiple fixes for various depth clipping issues (#17055, more)
  • VR has gained some new features (top-down perspective), new control options, and various fixes, thanks Lubos!
  • Several large code cleanups and refactors have been performed across the code base, to make future changes easier.
  • The RISC-V JIT compiler has been improved by [Unknown]. Future-proofs the emulator a bit!
  • New app icon (#11996), assorted bugfixes (#16988, #17017, more)
  • And much more!

Go get it!

Go download 1.15 now to benefit from all this!

The lens flare in Burnout

 

PSP rendering tricks - a new blog post series

In these posts, I'm going to look at some of the more interesting visual effects that games accomplish on the PSP, and how they do it. The PSP's GPU is very limited by modern standards, but it's still capable of quite a lot of interesting things if your really know how to use it.

Burnout Dominator's lens flare effect

First up, one of the trickiest lens flare effects seen on the PSP.

Lens flare effects are easy to do on modern GPUs. There are lots of different approaches, both image-based which can handle light sources of any shape but are generally not very detailed, and sprite-based, which are more limited in terms of the light source, but can look really complex and colorful. There are queries that can be used to figure out how many pixels actually got rendered when drawing the sun sprite, for example, that can be used to control the size and shape of the lens flare on the next frame, or you can read back the Z buffer directly while drawing the sprites.

On old-school, fixed-function hardware such as that of the PSP, where you can’t even do multitexturing, and definitely can’t run any shader code, people had to get quite imaginative to achieve these effects. And the authors of Burnout Dominator certainly were, as we will see.

Let's start by looking at the wrong result - the way it was in PPSSPP before I started investigating the effect:

As you can see, the lens flare effect is visible going into the tunnel, and through various trees and stuff.

There are two main parts to rendering a traditional lens flare correctly:

  • Determining the location, and measuring the sun coverage (how brightly the flare should render should be based on how much of the sun is covered by blocking things).
  • Using the determined coverage value, adjust the brightness of the lens flare. If the source of light is fully covered, no lens flare should be drawn, while if it’s partially covered or not covered at all, the lens flare should be drawn but with a brightness adjusted by the coverage.

Computing the sun coverage

To achieve this, here’s what Burnout Dominator does to measure the sun coverage, every frame:

First, it makes a backup copy of a 14x14 rectangle around the sun location on-screen, and then renders a black and a white rectangle on top, with only the black one being depth tested. The result is a binary mask of where the sun is visible.

It then downsamples (through bilinear filtering) this binary image to 8x8, sitting out in the unused border of the main framebuffer. Then, it downsamples this 8x8 image three more times, until we reach a single value, which is thus the average of the black and white pixels, and thus an effective measurement of the coverage. The final value is for some obscure reason spread out over four pixels.

Picture of downsampling

After that, it restores the little modified square of image the way it was, using the backup copy from before:

Restored image region

Applying the coverage value

So, we now have the coverage as a byte value. We could now treat this value as a 1x1 texture and let it influence the brightness of basic gouraud shaded geometry, like some simple hexagons and stuff, could look OK. Ridge Racer, for example, stops here (though uses a simpler accumulation method) - it draws simple shapes.

But Burnout gets fancier, and uses a nice lens flare texture. We are now faced with the challenge of how to use this arbitrary value sitting in an image, to influence the brightness of the lens flare texture, using only the PSP GPU. We do not want to use the CPU to copy the brightness value to some vertex colors, for example, as that would require expensive synchronization, instead we need to coax the GPU to do the work directly.

If we had multitexturing with combiners, or even shaders, we’d just sample this texel and multiply the lens flare texture by it, but we don’t have that. However, the PSP has some others features we can use - or misuse. Games on the PSP mostly use palletted textures, 4-bit or 8-bit indexed color. Palettes can be loaded from RAM or VRAM. And that opens up for a cute trick: Since on the PSP, memory is just memory, the game can actually overlay a render target on top of the palette memory belonging to the lens flare texture in memory, and render into the alpha channel of this render target, while texturing from a 1x1 texture carefully defined to overlap the brightness value from the previous coverage computation in memory! Then it can finally draw the lens flare using a texture with that modified CLUT loaded, which now has the correct alpha value in all colors, matching the coverage.

A problem with a deep solution

Except… The PSP is actually not able to write arbitrary values into the alpha channel of a 32-bit render target, at all! Not sure exactly why that is, but it is likely related to the fact that on the PSP, the alpha and stencil buffers share bits. So how do we actually accomplish it anyway, given that we just stated that it’s impossible?

This is where we get to the next level of trickery. When the game renders to the CLUT, it doesn’t use 32-bit color, instead it uses 16-bit “565” color, setting the render width to be 512, twice the size of the palette. Now, every second 16-bit pixel can be used to control the A and B channels of a color, and the other ones will control the G and R channels. The mapping is not trivial, let’s try to see that:

The same 32 bits in memory (each letter represents is 1 bit):

AAAAAAAA BBBBBBBB GGGGGGGG RRRRRRRR (one 32-bit color value)
bbbbbggg gggrrrrr bbbbbggg gggrrrrr (two 16-bit color values)
11111111 00000000 11111111 00000000 (bitmask for writing, see below)

When I said that it textures from the coverage value and writes it to the palette, what it really does is that it textures using another palette with a green-blue gradient to translate the coverage value into the appropriate green and blue bits to properly fill the alpha channel of the 32-bit CLUT entries, by rendering using 16-bit colors! The PSP GPU conveniently has a framebuffer bitmasking feature, where you can prevent writing to specific bits of each color value when rendering (modern GPUs don’t have that, they have a bit per channel instead), and it sets what's effectively a repeating 0xFF00 16-bit mask.

That creates a new problem though, it will now write that value to green as well in the corresponding 32-bit color values, as we can see in the diagram, which we don’t want. The color write bitmask is applied individually to each 16-bit pixel here, so that’s not very useful. So what can we use to mask away the writes to every other pixel? Well we are in fact using a GPU, so why not initialize a Z buffer with 0, 32767, 0, 32767, and use depth testing to discard every second value? And that’s what the game does, drawing to the palette, using a depth value and a depth compare function to make sure only every second 16-bit pixel actually gets written.

The result

And we reach the final moment, where the coverage value sits properly in the alpha channel of each entry of the color palette of the lens flare texture, and we can just do a simple draw to get it on the screen with the appropriate brightness.

Finally, we have:

Subtle working lens flare Bright working lens flare

And a video:

Phew! Getting this to work in PPSSPP was.. not trivial. I could write a whole other article about the improvements that needed to be done to the rendering pipeline so that all of the tricky steps above would actually work correctly.

Welcome to the new site!

 

Welcome to PPSSPP's new website!

Unlike the old one, this one has a blog. PPSSPP has long been missing a place to put those nice progress reports that the other big emulators release from time to time - also lacking the staff, but there will be content here similar to that!