ScummVM needs OpenGL with xBRZ support
Moderator: ScummVM Team
- Alien Grey
- Posts: 58
- Joined: Thu Sep 18, 2014 1:12 pm
- Location: Belgium
ScummVM needs OpenGL with xBRZ support
I think that OpenGL with xBRZ support should be added to ScummVM. This would make ScummVM games look a lot nicer without the need of slow scalers.
There's an unofficial ScummVM build with xBRZ support available from the xBRZ author. Perhaps someone should ask the xBRZ author to add official support for xBRZ to ScummVM.
There's an unofficial ScummVM build with xBRZ support available from the xBRZ author. Perhaps someone should ask the xBRZ author to add official support for xBRZ to ScummVM.
Alien Grey: It would have been useful to include a link to the xBRZ code and patches.
I have searched and found this here:
https://sourceforge.net/projects/xbrz/f ... p/download
This includes the latest xBRZ v1.5 patched into ScummVM v1.9.0.
xBRZ is licensed under GPLv3 so I think we can import this.
I can look at adding this as a Pull Request.
I have searched and found this here:
https://sourceforge.net/projects/xbrz/f ... p/download
This includes the latest xBRZ v1.5 patched into ScummVM v1.9.0.
xBRZ is licensed under GPLv3 so I think we can import this.
I can look at adding this as a Pull Request.
- Alien Grey
- Posts: 58
- Joined: Thu Sep 18, 2014 1:12 pm
- Location: Belgium
I don't mean that the scalers are actually slow but compared to xBRZ they are. xBRZ is faster than the HQ scalers and gives the same or better image. The HQ scalers in ScummVM gives an fps drop on my Windows 10 X64 device.Dark-Star wrote:What do you mean by "slow scalers"? I mean, even on my 6 year old rig the scalers impose no frame rate drop, they don't even increase CPU load measurably.
- Alien Grey
- Posts: 58
- Joined: Thu Sep 18, 2014 1:12 pm
- Location: Belgium
I didn't want to add a link because I don't know if this is allowed.digitall wrote:Alien Grey: It would have been useful to include a link to the xBRZ code and patches.
I have searched and found this here:
https://sourceforge.net/projects/xbrz/f ... p/download
This includes the latest xBRZ v1.5 patched into ScummVM v1.9.0.
xBRZ is licensed under GPLv3 so I think we can import this.
I can look at adding this as a Pull Request.
It would be awesome if this could be imported to ScummVM. I think it gives the best result with xBRZ and bilinear filtering disabled. The image looks nice, smooth and still sharp like that. With bilinear filtering enabled it starts to look a bit blur.
- rootfather
- ScummVM Lead
- Posts: 182
- Joined: Tue Mar 31, 2015 11:59 am
- Location: Germany
- Contact:
rootfather: I have managed to get the xBRZ source and the modified v1.9.0 source code. However, the modified ScummVM source code has a lot of "noise" due to IDE auto-formatting and other unrelated changes.
I started a branch to look at cleaning up the required source changes so they can be reviewed, but haven't got this to a clean state yet. The changes are functionally limited to four files:
backends/graphics/opengl/opengl-graphics.{cpp,h}
backends/graphics/opengl/texture.{cpp,h}
However, this means that the filter is "hacked" into the OpenGL backend and will not be available for other backends.
Apart from this, the actual xBRZ code is provided by an object file dropped in from the zBRZ project and no porting or hooking of that code into ScummVM has been done.
Overall, this is a good proof of concept hack and working code, but it can't be merged as-is without some fairly major work :/
I started a branch to look at cleaning up the required source changes so they can be reviewed, but haven't got this to a clean state yet. The changes are functionally limited to four files:
backends/graphics/opengl/opengl-graphics.{cpp,h}
backends/graphics/opengl/texture.{cpp,h}
However, this means that the filter is "hacked" into the OpenGL backend and will not be available for other backends.
Apart from this, the actual xBRZ code is provided by an object file dropped in from the zBRZ project and no porting or hooking of that code into ScummVM has been done.
Overall, this is a good proof of concept hack and working code, but it can't be merged as-is without some fairly major work :/
rootfather: Have now managed to clean up the xBRZ patch to the ScummVM source, which is here and shows the remaining issues I indicated:
https://github.com/digitall/scummvm/tre ... 1-9-0_xBRZ
https://github.com/digitall/scummvm/com ... e6220f9714
https://github.com/digitall/scummvm/tre ... 1-9-0_xBRZ
https://github.com/digitall/scummvm/com ... e6220f9714
Awesome.digitall wrote:rootfather: Have now managed to clean up the xBRZ patch to the ScummVM source, which is here and shows the remaining issues I indicated:
https://github.com/digitall/scummvm/tre ... 1-9-0_xBRZ
https://github.com/digitall/scummvm/com ... e6220f9714
To be clear, I was a bit understated when I said "minor formatting cleanup". The v1.9.0 code changes were not supplied as a patch file, so I have to locate the correct base revision to difference against and there was a fair amount of IDE / editor auto-formatting cruft on the changed files that took me quite a while to unpick to get this commit with clean diff / patch for review.
However, it is clear that this is "hacked in" a bit and the changes will break things if applied as-is so some work is needed to assess if this is the correct approach and location to add this code or whether it should be implemented by the shaders API as per other filters.
Apart from that, it pulls in several std library parts which may not be present on all ports and should be replaced by Common code usage and/or rewritten... and even then I haven't managed to build this as the external xBRZ code needs a separate build ... and I am still not sure if this needs some changes to get this to build and link correctly.
The tl;dr is don't hold your breath on this being merged, at least as-is.
However, it is clear that this is "hacked in" a bit and the changes will break things if applied as-is so some work is needed to assess if this is the correct approach and location to add this code or whether it should be implemented by the shaders API as per other filters.
Apart from that, it pulls in several std library parts which may not be present on all ports and should be replaced by Common code usage and/or rewritten... and even then I haven't managed to build this as the external xBRZ code needs a separate build ... and I am still not sure if this needs some changes to get this to build and link correctly.
The tl;dr is don't hold your breath on this being merged, at least as-is.
-
- Posts: 7
- Joined: Tue Feb 20, 2018 6:02 pm
Raziel: Did a bit more work so that all the required source files are in commits on my branch. Discovered that this depends on the Microsoft Parallel Patterns library, which is Windows only / non-portable, so no chance of merging this as-is unless we can rewrite the code to remove that dependency.
https://github.com/scummvm/scummvm/comp ... 1-9-0_xBRZ
https://github.com/scummvm/scummvm/comp ... 1-9-0_xBRZ