<p>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
![Tongue]( "Tongue")
That said, here are the most notable changes since the last report</p>
<p><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/progrepq22017.jpg" alt="Progress report q2 2017" width="563" height="104" style="display: block; margin-left: auto; margin-right: auto;" border="0" /></p>
<p><br /> <br /> <span style="color: #ff3333;">[Bug-Fix]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1907" target="_blank" rel="noopener noreferrer">PCSX2: Fix command-line options</a></span> by <a href="https://github.com/turtleli" target="_blank" rel="noopener noreferrer">turtleli</a><br /> <br /> Since the <a href="http://forums.pcsx2.net/Thread-blog-The-return-of-the-Commandline?pid=118520&highlight=commandline#pid118520" target="_blank" rel="noopener noreferrer" class="mycode_url">re-addition of the command-line interface</a> 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:</p>
<ul>
<li>Booting the ISO from the commandline would fail when CDVD plugin is selected on the PCSX2 GUI and vice versa.</li>
<li>The --nodisc command line option failed to work.</li>
<li>The current ISO selection was cleared when any boot source other than ISO was used in the command line.</li>
</ul>
<p><span class="mycode_b" style="font-weight: bold;">Turtleli</span> has fixed all of these issues and the command line options are now back to functioning properly as they should.<br /> <br /> <span style="color: #ff3333;">[Bug-Fix]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/2014" target="_blank" rel="noopener noreferrer">PCSX2-Counters: Proper tracking of scalar limit</a></span> by <a href="https://github.com/turtleli" target="_blank" rel="noopener noreferrer">ssakash</a><br /> <br /> 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.<br /> <br /> 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.<br /> <br /> <span style="color: #9970f9;">[Upstream]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1949" target="_blank" rel="noopener noreferrer">CMake: Blacklist GCC 7.0/7.1 versions</a></span> by <a href="https://github.com/gregory38" target="_blank" rel="noopener noreferrer">Gregory</a><br /> <br /> It recently came to our attention that hardware rendering has severe issues when PCSX2 is compiled using GCC versions 7.0 and 7.1 (<a href="https://github.com/PCSX2/pcsx2/issues/1937" target="_blank" rel="noopener noreferrer" class="mycode_url">#1937</a>). After analyzing the issue, we found out that these versions have some issues with generating MMX opcodes. A <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799" target="_blank" rel="noopener noreferrer" class="mycode_url">bug report</a> regarding the issue was filed on the GCC bug tracker and it was dealt with quickly thanks to the GCC developers.<br /> <br /> 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.<br /> <br /> <span style="color: #018ddd;">[Enhancement]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1922" target="_blank" rel="noopener noreferrer">GSdx: Support for dumping GS Dumps in xz format</a></span> by <a href="https://github.com/gregory38" target="_blank" rel="noopener noreferrer">Gregory</a> and <a href="https://github.com/turtleli" target="_blank" rel="noopener noreferrer">turtleli</a><br /> <br /> 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.<br /> <br /> There are two different ways available for capturing GS dumps:</p>
<ul class="mycode_list">
<li><span class="mycode_b" style="font-weight: bold;">SHIFT + F8</span> - Single frame dump. (Captures GS information of a single frame)</li>
<li><span class="mycode_b" style="font-weight: bold;">CONTROL + SHIFT + F8</span> - Multiple frame dump (Captures GS information until you stop pressing your control key)</li>
</ul>
<p><br /> 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.<br /> <br /> <span style="color: #ff6347;">[Optimization]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1995" target="_blank" rel="noopener noreferrer">GSdx-OpenGL: Reduce Geometry shader overhead</a></span> by <a href="https://github.com/gregory38" target="_blank" rel="noopener noreferrer">Gregory</a><br /> <br /> 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.<br /> <br /> Here are some benchmarks of the change taken from Nouveau/Mesa drivers.<br /> <br /> <a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/shader-opt.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/shader-opt.png" alt="Shader Optimisation" width="640" height="327" title="Shader Optimisation" border="0" /></a> <br /> <br /> 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.<br /> <br /> <span style="color: #ff6347;">[Optimization]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1942" target="_blank" rel="noopener noreferrer">GSdx-HW: Revamped buffer size calculation for custom resolutions</a></span> by <a href="https://github.com/ssakash" target="_blank" rel="noopener noreferrer">ssakash</a><br /> <br /> There is a certain configuration option of GSdx known as <span class="mycode_b" style="font-weight: bold;">"Large Framebuffer"</span>. When enabled, this option would increase the emulation accuracy in upscaled resolutions at the cost of extra workload on the GPU.<br /> <br /> Here's an example showing the effect of <span class="mycode_b" style="font-weight: bold;">Large Framebuffer</span> on ICO,<br /> <br /> <a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/ico-before.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/ico-befores.png" alt="Ico Before" width="353" height="353" title="Ico Before" border="0" /></a> <a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/ico-after.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/ico-afters.png" alt="Ico after" width="353" height="353" title="Shader Optimisation" border="0" /></a> <br /> Disabling the <span class="mycode_b" style="font-weight: bold;">Large Framebuffer</span> 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.<br /> <br /> To avoid such cases, <span class="mycode_b" style="font-weight: bold;">ssakash</span> 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.<br /> <br /> In a nutshell, this is how the new algorithm works compared to the previous one.</p>
<div class="codeblock">
<div class="title">Code:</div>
<div class="body" dir="ltr"><code># Previous code<br />
if ( Large Framebuffer )<br />
IncreaseFramebufferSize();<br />
<br />
# New code<br />
if ( Large Framebuffer )<br />
{<br />
if ( IsExtraBufferSizeNecessary() )<br />
IncreaseFramebufferSize();<br />
}</code></div>
</div>
<p><br /> 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.<br /> <br /> <a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/old-algo.gif" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/old-algo.gif" alt="Old Algorithm" width="480" height="270" title="Old Algorithm" border="0" /></a> <a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/new-algo.gif" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/new-algo.gif" alt="New Algorithm" width="480" height="270" title="New Algorithm" border="0" /></a> <br /> Now you can safely enable <span class="mycode_b" style="font-weight: bold;">Large Framebuffer</span> on custom resolutions without worrying about any useless GPU overhead.
![Smile]( "Smile")
<br /> <br /> <span style="color: #018ddd;">[Enhancement]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1895" target="_blank" rel="noopener noreferrer">Onepad: Update to use SDL2</a></span> by <a href="https://github.com/gregory38" target="_blank" rel="noopener noreferrer">Gregory</a><br /> <br /> 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.<br /> Here's how it worked with SDL 1.2: <br /><a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl1.2_process.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl1.2_process_s.png" alt="SDL 1.2" width="493" height="150" title="SDL 1.2" border="0" /></a> <br /> 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.<br /><br /> Here's a nice schema for the new implementation: <br /><a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl2_process.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl2_process_s.png" alt="SDL 2" width="492" height="150" title="SDL 2" border="0" /></a></p>
<p>Thanks to everyone who collected the info and helped with this report once more, you know who you are
![Smile]( "Smile")
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!</p>
![[Image: kI5eLdR.png]](http://i.imgur.com/kI5eLdR.png)
![[Image: 1mJdsDc.png]](http://i.imgur.com/1mJdsDc.png)
That said, here are the most notable changes since the last report</p>
<br /> <br /> <span style="color: #018ddd;">[Enhancement]</span> <span style="font-weight: bold; text-decoration: underline;"><a href="https://github.com/PCSX2/pcsx2/pull/1895" target="_blank" rel="noopener noreferrer">Onepad: Update to use SDL2</a></span> by <a href="https://github.com/gregory38" target="_blank" rel="noopener noreferrer">Gregory</a><br /> <br /> 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.<br /> Here's how it worked with SDL 1.2: <br /><a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl1.2_process.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl1.2_process_s.png" alt="SDL 1.2" width="493" height="150" title="SDL 1.2" border="0" /></a> <br /> 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.<br /><br /> Here's a nice schema for the new implementation: <br /><a href="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl2_process.png" target="_blank" rel="noopener noreferrer"><img src="https://pcsx2.net/images/stories/frontend/progress_reports/q2-2017/sdl2_process_s.png" alt="SDL 2" width="492" height="150" title="SDL 2" border="0" /></a></p>
![[Image: eYa6g5D.png]](http://i.imgur.com/eYa6g5D.png)
