Why AnyPS5 fell from 91% to 64%: the recorded function inventory and stub change
ItsOOGWAY · PC guides & recorded tests
Why AnyPS5 fell from 91% to 64%: the recorded function inventory and stub change
AnyPS5's system library coverage dropped from above 91% to around 64%. Did the project lose progress? The implemented count actually increased while the total number of declared functions grew much faster.
The key checkpoint: Read implemented functions and declared functions together. More named pending exports can lower the percentage without removing existing implementations.
How to read the evidence
- Keep the date, source revision, scene and measurement unit with each claim.
- Contributor reports and earlier local gameplay are attributed evidence, not a new benchmark.
- Use the primary documents below to check later changes.
Dated snapshot: the recording discusses 4,284 implemented functions and roughly 64% coverage on October 20. The live history now recalculates that date as 4,325/6,874 (62.92%) using current counting rules. Preserve both the date and revision when comparing. Current official history.
Resources from this video
Links, downloads & documentation
Primary documents, attributed reports and every source URL from the video description are collected here. Preserve the date and measurement context when comparing later updates.
Watch the complete video
Open this video on YouTube ↗. Screenshots below link to their exact recorded moments.
Walkthrough 01
Understand the coverage counter
First, what is this counter actually measuring? Games depend on system functions for things like memory, input, audio, and communication with the operating system. AnyPS5 provides its own implementations of system libraries that games expect to use. The progress counter compares functions counted as implemented with the functions currently declared in the project. It has never been a complete inventory of everything the PlayStation five can do. That means the total can grow when more missing functions are added to the codebase.
The older percentage was a percentage of the smaller list known to the tracker at that point.
Walkthrough 02
Compare the recorded daily snapshots
Here's what the official history shows. For October eighteenth, it lists three thousand, six hundred and eighty-three implemented functions, out of four thousand and twenty-nine declared functions. That's just over ninety-one percent. In the October twentieth snapshot we're looking at, the implemented count has increased to four thousand, two hundred and eighty-four. But the declared total is now above six thousand, six hundred. So the tracker counts six hundred and one more functions as implemented, while the tracked workload has expanded much faster.
That's how the percentage can fall while the implemented count rises.
Walkthrough 03
Keep historical counting rules in view
These historical figures are recalculated using the project's current counting rules, which makes them a comparison of those code snapshots under the same rules.
Walkthrough 04
Read the pending-export change
There's a particularly clear example in this pull request. It adds five hundred and ninety-two pending exports across two system libraries. You can think of exports as functions a library makes available for another program to request. In the comparison reported here, the implemented count stays exactly the same. Only the declared total increases. The reported percentage drops from about eighty-three percent to about seventy-three percent, without the implemented count going down. Those are the figures for this particular change, separate from the daily history.
This one pull request doesn't explain the entire two-day change, but it demonstrates the effect directly.
Walkthrough 05
Distinguish stubs from working behavior
There's an important distinction, though. Declaring a function does not mean its behavior has been implemented. These additions are stubs: placeholders that explicitly report that the behavior is not implemented. They can let a missing import resolve, but if the game calls that unsupported function, it can still stop there. That makes the gap visible. Developers can identify what the game needs, investigate how it should behave, implement it, and test the result. A missing requirement doesn't become unnecessary just because it was absent from a progress chart.
And even the implemented category needs context. The scanner classifies code; it doesn't prove that every function behaves correctly in every game. Incomplete behavior can still remain.
Walkthrough 06
Look for game evidence beyond the percentage
So does this update mean better frame rates? These numbers alone can't tell us that. Correct library behavior matters, but performance also depends on the graphics path, synchronization, memory handling, and the particular game being tested. Resolving one blocker might get a game further without making it faster. What I find encouraging is that the project is making more of the remaining work explicit, while the tracked implemented count continues to grow in these snapshots.
For actual game progress, look for a report naming the build, the hardware, how far the game runs, and what still fails.
Checks for interpreting the report
| Situation | Next useful check |
|---|---|
| A current source differs from the recording | Keep the recorded snapshot date. Check current revision and measurement rules before comparing. |
| A screenshot appears to prove more than the report | Read the full source, the test environment and the untested limitations. |
| A headline number sounds decisive | Check its numerator, denominator, time unit and the specific outcome it measures. |
Comments
Post a Comment