Hello followers and welcome to the Q2 2017 progress report. You might notice it's not as exciting as the previous report, but that is because the PCSX2 team has always slacked during summer time so this was to be fully expected
That said, here are the most notable changes since the last report
Since the re-addition of the command-line interface by former developer Air, the command-line code has remained untouched for years with issues arising on it as the other areas of the emulator were improved. The known issues of the command line interface were:
- Booting the ISO from the commandline would fail when CDVD plugin is selected on the PCSX2 GUI and vice versa.
- The --nodisc command line option failed to work.
- The current ISO selection was cleared when any boot source other than ISO was used in the command line.
Turtleli has fixed all of these issues and the command line options are now back to functioning properly as they should.
PCSX2 allows modification of the base framerate limit in the Emulation settings dialog. The value of the base framerate limit is 100% by default and can be modified to effectively increase/decrease the speed of the game.
We recently found out that the framerate limit wasn't updated according to the value requested by the user, due to a discrepancy in resetting the vertical synchronization timer logic whenever new settings were written to the emulator. The issue has now been fixed by forcing the reset of the timer logic whenever the emulation settings are updated.
It recently came to our attention that hardware rendering has severe issues when PCSX2 is compiled using GCC versions 7.0 and 7.1 (#1937). After analyzing the issue, we found out that these versions have some issues with generating MMX opcodes. A bug report regarding the issue was filed on the GCC bug tracker and it was dealt with quickly thanks to the GCC developers.
To prevent users from compiling PCSX2 on these affected versions, an error will now be displayed advising the user to back-port the fixed version or update GCC.
A GS dump is a file which holds the data processed by the Graphics synthesizer during a specific amount of time. This file is generated with the help of the GSdx plugin and utilizing this, the developers could easily replay the graphical bugs recorded by the users on the dump.
There are two different ways available for capturing GS dumps:
- SHIFT + F8
- Single frame dump. (Captures GS information of a singleframe)
- CONTROL + SHIFT + F8
- Multiple frame dump (Captures GS information until you stop pressing your control key)
GS dumps are generally large in size and they could even exceed the size of 1 GB at some cases when capturing multiple frame dumps! To avoid creating huge files, GS dumps are now directly dumped in the .xz format for single frame dumps. Compression is only limited to single frame dumps for now as multiple frame dumps take longer time to compress leading to a freeze for several minutes.
The GLSL shader operations were modified in order to reduce the overhead in the geometry shader. This reduction in overhead is achieved by outputting 1 strip of 2 triangles instead of 2 strips of 1 triangle at certain scenarios.
Here are some benchmarks of the change taken from Nouveau/Mesa drivers.
However, the performance gain on games should be very small. You might gain 1-2 fps at most cases and potentially higher if the bottleneck is the geometry shader execution.
There is a certain configuration option of GSdx known as "Large Framebuffer" . When enabled, this option would increase the emulation accuracy in upscaled resolutions at the cost of extra workload on the GPU.
Here's an example showing the effect of Large Framebuffer on ICO,
Disabling the Large Framebuffer option could cause severe glitches in upscaled resolutions like the one shown above but only a limited amount of games seem to rely on this option to function properly, so the extra GPU workload introduced by enabling this option would end up useless at games which don't need it.
To avoid such cases, ssakash has implemented a new buffer size calculation algorithm which increases the framebuffer size only at necessary scenarios. This effect is achieved by monitoring the scissoring values of the frame memory.
In a nutshell, this is how the new algorithm works compared to the previous one.
# Previous code
if ( Large Framebuffer )
# New code
if ( Large Framebuffer )
if ( IsExtraBufferSizeNecessary() )
This new algorithm improved performance significantly on GS intensive testcases and provided around 2-5% performance boost on normal test cases. For example - On the previous algorithm, Ben 10 Alien Force: Vligax Attacks (rendering at 3840x2160) took over 20 seconds to even pass the loading screen! After this new implementation, it barely takes 3 seconds to pass the loading screen.
Now you can safely enable Large Framebuffer on custom resolutions without worrying about any useless GPU overhead.
The Onepad plugin uses the SDL library to query the controller and interpret the raw input into game actions. These inputs vary per controller and are troublesome to deal with as you need to map the kernel information to the PS2 equivalent value. Here's how it worked with SDL 1.2:
Upgrading SDL to version 2.0, we present a generic virtual controller abstracting the kernel information to Onepad. The values in the virtual controller are then mapped to their respective PS2 equivalent values. This gives us support for plug and play, automatic button mapping along with reduction in code complexity of Onepad. On the other hand, this change has also removed support for pressure sensitivity and the ability to manually remap the controller. The legacy Onepad versions are still available for the support of these features until they're added to the latest version of Onepad.
Here's a nice schema for the new implementation:
Thanks to everyone who collected the info and helped with this report once more, you know who you are
Next time I promise I'll post some news about our website, forum and wiki being updated along with some new handy features for our community. Stay tuned!