Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Q4 2016 progress report
#1

Progress report q4 2016


Finally the Q4 2016 progress report! Yes we know it's a bit late but you will find it was worth the wait! On to the changes:

[Portability]   cdvdgigaherz: Linux port by turtleli

cdvdGigaherz was originally a Windows only CD/DVD disk reading plugin. However, by using portable code to replace as much of the Windows specific code as possible and adding a Linux disk reading backend and GUI, cdvdGigaherz now works on Linux.

[Bug-Fix]   PSX mode compatibility by Rama and Pseudonym

Previously, PCSX2 had always failed to play PSX games due to unimplemented devices that are necessary for backward compatibility. Rama had then decided to reach out to other developers to fix the problem. He found someone on the assemblergames.com forums that just so happened to be an expert on PS2's IOP sub bus hardware: wisi! Wisi implemented the missing PGIF device, added the required hardware hooks and with that PCSX2 was finally able to boot into PSX mode!

However, most of the PSX games still suffered from bad audio and the source of the issue was the SPU2 plugin. It was assumed that in the backward compatibility mode of the SPU2, the hardware provides a mapping window into SPU2 RAM, which wasn't properly handled by the plugin. Pseudonym then fixed all the issues related to the mapping management and SPU2-X started providing much better results. At this time, he also redid the reverb algorithm (which is shared between PSX and PS2 modes) and improved it significantly towards an exact replica of the original. The following waveform comparison shows that there are still some unsolved problems with the pulse response, but the delay and feedback are spot on! It sounds much better than the older implementation and benefits PSX and PS2 games alike.

SPU2-X reverb

Here are some screenshots of Tekken 3, Ridge Racer and Driver running under PCSX2's brand new PSX mode:
Tekken 3 Driver

Ridge Racer

Note:
  • PSX backward compatibility is still in its nascent state, so bug reports related to it will be dismissed, until the emulation has matured enough.
  • Also quite interesting: None of the PSX emulators used for comparison produces reverb waveforms that look anything like the original hardware!
[Bug-Fix]   PSX mode: Proper video mode initialization by ssakash

PCSX2 initializes the video modes based on the parameters of the SetGsCrt() function call, however, only PS2 games made use of this SYSCALL and PSX games didn't, this left all the PSX games in an uninitialized video mode state making them susceptible to various timing issues.

ssakash fixed this issue by initializing the video mode based on the color subcarrier frequency (CMOD) when the video mode is at an uninitialized state, this change finally made PAL PSX games to output at their proper vertical frequency.

[Enhancement]   LilyPad: Add separate bindings for each pad type by FlatOut

Before this update, all pad types (DualShock 2, Guitar, Pop'n Music controller) shared the same button configuration. But your ideal setup for the DualShock 2 might not be the same as your preferred Guitar setup, so you had to change the button configuration or load another LilyPad configuration each time you wanted to play a game with the one of the other pad types. This has now been resolved by giving each of the pad types their own individual configuration.

[Enhancement]   LilyPad: Add PlayStation Mouse support by FlatOut

The PlayStation Mouse has been added as a new pad type. This mouse can be used on a number of PS1 titles such as Myst and Sim City 2000. There are no known PS2 titles that support it, but thanks to PCSX2's new PSX backward compatibility, you can now use it with PCSX2.

[Enhancement]   LilyPad: Updated user interface by FlatOut

The LilyPad user interface has been updated by removing some of the buttons below the diagnostics and input bindings lists and incorporating those into the corresponding list as right-click options. The functionality is also still available by keyboard input. The input configurations on the Pad tabs have been moved to a separate page - like the force feedback configuration - to clearly separate the configuration options from the available bindings.

Additionally, several informational tooltips have been added to better explain how the LilyPad options work, which should help setting up LilyPad just the way you want it.

Three new options have been added to the Pad tabs. A device select option that hides bindings and disables binding new inputs from all non-selected devices on the bindings list. This also avoids input conflict issues when one controller is recognized as several devices through different APIs.

A skip deadzone option has been added to the input configuration page. With the normal dead zone, if the control input value is below the given threshold value, the input is just ignored. However, some controllers benefit from shortening the input range by skipping a deadzone. This allows most of the movement of the input to be used and it will require less movement before your input is picked up by a game.

The third new option is a "configure on bind" checkbox. With this enabled you'll be sent straight to the input configuration for each input you bind.

Lilypad UI Lilypad UI


[Bug-Fix]   GSdx: Hardware mipmapping support by Gregory

Previously, all the hardware renderers suffered from mipmapping issues due to various unimplemented functions. For example, whenever mipmapping is performed, it is necessary to set the base pointer address and the buffer width of the textures of two (or) more mimpap levels, even this basic function was not emulated before as there wasn't much priority on getting mipmapping to work on hardware renderers.

The main reasons were that only some few games (around 10-30) had mipmapping related issues which is quite a small amount of games in comparison to the whole PS2 library and there was also a possibility that mipmapping could influence the performance negatively, so none of the developers were planning on tackling it, as at that time, there were far more severe bugs related to the CLUT, Texture cache, display rectangle setup and Z buffer which were more prioritized.

Most of the end users didn't really understand our priorities and there were lots of negative posts related to not implementing hardware mipmapping and it grew out of control as we kept releasing our progress reports. There were even some rumours spreading that hardware mipmapping is impossible without a rewrite of texture cache. To shut them all up, Gregory took all the responsibility in his hands and finally added support for hardware mipmapping!

Ratchet and Clank Ratchet and Clank

Ratchet and Clank Ratchet and Clank

Ace Combat 4 Ace Combat 4


Note: The current implementation of hardware mipmapping isn't totally accurate, the current implementation replaces the pointer of the base layer with the LOD min layer, assuming that it contains valid data. While the current hardware mipmapping implementation isn't really ideal, it fixes issues with most of the games (Ratchet & Clank, Ace Combat, Legacy of Kain) even with increase in performance in certain scenarios!

Unfortunately, there are still a few games requiring full mipmapping support which will be quite hard to tackle without compromising on performance.


[Bug-Fix]   GSdx-TextureCache: Proper scaling of all textures by Gregory and ssakash

On games like Devil May Cry, a few textures weren't being scaled properly, which lead to graphical glitches on the upper left part of the screen at upscaled resolutions. Eventually we had found out that in certain rare cases when the Texture-cache target was created, the scaling of the textures was omitted.

Gregory fixed the issue by properly scaling the textures at such cases with respect to the integral scaling value, ssakash later generalized the scaling equation to also make it work on custom resolutions.

Devil May Cry Devil May Cry


[Bug-Fix]   GSdx: Handling illegal 8 bits pixel storage format by Gregory

The Graphics Synthesizer supports 3 different color formats for the frame buffer,

  • 32 bits (RGBA8): 3 color channels of 8 bits + 1 alpha channel of 8 bits. (PSMCT32)
  • 24 bits (RGB8): 3 color channels of 8 bits. (PSMCT24)
  • 16 bits (RGB5A1): 3 color channels of 5 bits + alpha channel of 1 bit. (PSMCT16, PSMCT16S)

However, some games seem to use an illegal format at the FRAME register, a format known as PSMT8H. The valid and sane hypothesis was that the core is sending some garbage values to GSdx, so skipping the draw call might fix it. However, that wasn't the case. A developer was indeed crazy enough to send such an insane value!

Gregory had resolved the issue by replacing the illegal format with a valid 32 bit format and channel masking in the FBMSK bitfield of FRAME register.

Berserk Berserk



[Bug-Fix]   GSdx-PCRTC: Feedback write support by Gregory

The graphics synthesizer contains a dedicated hardware to handle the presentation of the framebuffer to the output circuit, the hardware can merge two contexts of framebuffer together based on various parameters, however there's also an alternative way to write back data in the frame buffer.

Using the feedback write circuit, we can write a specific rectangular area in the output image to an arbitrary position in a local buffer at an arbitrary sampling rate dependent on the status of feedback write setting registers. The data can be a raw copy, but RGB->YCbCr conversions could also be requested based on the feedback write setting.

Gregory has now implemented feedback write support on the OpenGL hardware and software renderer which fixes issues with various games along with the infamous Xenosaga I dream scenes which make use of feedback write circuit, the DirectX port for the fix is yet to be done as there aren't really any active DX developers on our team at the moment.


Xenosaga Xenosaga

Xenosaga makes use of the feedback write mechanism to convert the color to a luminance greyscale.

And that was it for this quarter's progress report! There were several other changes that haven't made it in this report since as you can see it's already pretty huge, but we believe we covered everything important for our users.

We could use some extra help preparing and writing these reports, so if anyone is interested, has time and is up to the task please inform us by posting HERE in our forum.

As always, check out our progress over the Github repository, help us by reporting issues or by sending pull requests, even if your code still needs work. Our coders and contributors will be more than happy to help you help us with your changes, improvements and bug fixes to our code!

As usual a big thank you to all people who contributed to this report, bug squad members and coders alike you know who you are!
Till next time, keep playing. Smile
[Image: newsig.jpg]
Reply

Sponsored links

#2
Great read, loving the work. Although I do have a question. When will a new stable build be released? I know you can download the development builds, but I kind of like to stick to stable builds.

In any case, great stuff there Laugh
Reply
#3
(02-02-2017, 07:31 PM)Ryu Makkuro Wrote: Great read, loving the work. Although I do have a question. When will a new stable build be released? I know you can download the development builds, but I kind of like to stick to stable builds.

In any case, great stuff there Laugh

The next stable build will probably be released in the next few months. To be honest, the development builds are perfectly stable as crashing rarely occurs.

We only release one stable build a year, so they become obsolete very quickly (80% of users generally get referred to development builds just because of the significant reduction in bugs/crashes, ect). You're missing out on alot of enhancements but to each their own I guess Tongue
[Image: 36a66c559937a1f5d0cd7460362d4093.jpg?bg=2c2c2c]
Reply
#4
(02-02-2017, 09:55 PM)CK1 Wrote: The next stable build will probably be released in the next few months. To be honest, the development builds are perfectly stable as crashing rarely occurs.

We only release one stable build a year, so they become obsolete very quickly (80% of users generally get referred to development builds just because of the significant reduction in bugs/crashes, ect). You're missing out on alot of enhancements but to each their own I guess Tongue

Can vouch, haven't used 1.4.0. since August.
Hey,  I'm writing yet another PCSX2 frontend. Source code is being hosted at GitHub.
Reply
#5
(02-02-2017, 09:55 PM)CK1 Wrote: The next stable build will probably be released in the next few months. To be honest, the development builds are perfectly stable as crashing rarely occurs.

We only release one stable build a year, so they become obsolete very quickly (80% of users generally get referred to development builds just because of the significant reduction in bugs/crashes, ect). You're missing out on alot of enhancements but to each their own I guess Tongue
There is no set date for the new stable build, so let's say this year as opposed to in the next few months.

Most stable releases actually had 2 years or so in between them, there is no real schedule to it. 80% of the users might get referred to the dev builds, but that doesn't only happen because of the many changes since v1.4.0. They will get referred to a dev version even if latest stable build is only a few weeks old. Because if they have an issue they can't resolve, it could have been fixed since and we need to make sure we're not helping them resolve an issue that's already been taken care of. Smile

v1.5.0 builds are much better than v1.4.0 in a lot of ways, but waiting until the next stable release will give even more improvements and the changes will stand out more than when you've already tried the v1.5.0 builds, so there is the benefit of a bigger wow factor. Tongue2
Reply
#6
You staff members do a lot amazing work! You fixed a couple of games that I really enjoy such as the Time Crisis 2/3 games with the 2 player split-screen mode. you fixed the Half white screen in mercenaries 1 in openGL and made Swat: Global Strike team playable instead of having a green screen. There are other fixes I have seen from youtube videos of games I don't play but this is the best work I have seen! Keep it Goin! Laugh
Reply
#7
"We could use some extra help preparing and writing these reports, so if anyone is interested, has time and is up to the task please inform us by posting HERE in our forum."

Yes, Iam.... Smile
Reply
#8
(02-02-2017, 10:48 AM)Bositman Wrote: We could use some extra help preparing and writing these reports, so if anyone is interested, has time and is up to the task please inform us by posting HERE in our forum.

I'd be happy in helping out with either collection of bug reports, assisting in writing reports of talking with devs about the changes.
[Image: zRORpDo.png]
Reply
#9
There seems to be an issue with "GSdx-TextureCache: Proper scaling of all textures by Gregory and ssakash" "after" screenshot... ?

It seems like the health bar and the red orbs are upscaled along with their (native res. ?) "frame" (their inherent top background part) and as a result, there's a "band" of lower resolution at the top.
Reply
#10
The health bar and orb counter are probably a 2D overlay of the game, thus not getting upscaled like the rest of the view, which makes them stand out
[Image: newsig.jpg]
Reply




Users browsing this thread: 1 Guest(s)