[garbear]

So I think we should definitely use the physical layout as the default (the same as Retroarch does) to preserve the original game's ergonomy.

I agree with this. We should have all button maps preserve the original game's ergonomy. Any and all button maps that need to be updated we should update.

[KOPRajs]

I agree with this. We should have all button maps preserve the original game's ergonomy. Any and all button maps that need to be updated we should update.

I'm sorry, but I've found out that it cannot be done as I was suggesting. The buttonmap.xml of the individual cores are correct. They need to exactly reflect the mapping inside the core's code, otherwise we break the manual re-mapping, so we need to keep those as they are.

If we want to change the default mapping, we need to find another way of doing it.

[KOPRajs]

@garbear I don't use Kodi in Windows regularly, but I've had a chance, so I've just tested the current build from https://github.com/garbear/xbmc/releases.

In general it works great and the new enhanced Savestate manager is nice, but I've come across 2 bugs:

1. I can't start a game at all in the most recent build (2023-02-01), if there are no savestates present. Clicking on the game file doesn't open the emulator selection window. There is "No compatible game client selected" error in the log. It is working in the build from 2023-01-31, so probably the last change ("Totally redone out-of-game Savestate Manager") is missing a case for "if there are no savestates, open the select emulator window instead".

2. The "confirm" action ("enter", "left click" or "A" by default) doesn't work in the "Video filter" and in the "Stretch mode" in-game menus. It is probably related to the addition of the context menu to the "Save / Load" menu. You can still change the shader or the stretch mode and then click "back" instead of "confirm" as a workaround.
This is broken even in the current Nexus nightly, so we should try to fix it before v20.1 is released!

[zachmorris]

Can confirm the same issue in linux and OSX. Nothing will launch and the log shows no suitable players available (even though there are).

[garbear]

1. I can't start a game at all in the most recent build (2023-02-01), if there are no savestates present. Clicking on the game file doesn't open the emulator selection window. There is "No compatible game client selected" error in the log. It is working in the build from 2023-01-31, so probably the last change ("Totally redone out-of-game Savestate Manager") is missing a case for "if there are no savestates, open the select emulator window instead".

Fixed in the latest round of test builds.

2. The "confirm" action ("enter", "left click" or "A" by default) doesn't work in the "Video filter" and in the "Stretch mode" in-game menus. It is probably related to the addition of the context menu to the "Save / Load" menu. You can still change the shader or the stretch mode and then click "back" instead of "confirm" as a workaround.

It's caused by the new menu. I'll prepare a fix when I get a chance.

This is broken even in the current Nexus nightly, so we should try to fix it before v20.1 is released!

I'll make sure v20.1 is working perfect before it's released.

[KOPRajs]

GL shaders were disabled a while ago because, while they didn't work on GL, at least they didn't cause problems. But then on macOS the screen was entirely black, so I disabled. Recently, I tried enabling, and now they definitely cause problems even on Linux. So yeah, GL shaders need some love.

@garbear I've just returned from family holidays with a friend who is a developer (unlike me). While our families went to sleep at night, we got an idea to hack a little bit, so we sneaked to a computer and played with the https://github.com/garbear/xbmc/pull/114.

The good news is that it is actually not broken, as we've managed to create a Linux build (Wayland and OpenGL) from your repository (retroplayer-20 branch) with the "reverted revert of the PR114". We added the ShaderPresetsGLSLP.xml and the actual GLSL shaders to game.shader.presets and we've got working shaders on Linux! Even more, while the PR description states that the live preview of the shaders is not supposed to work, it actually worked for us, see the screenshots:


However, as you can see in the second screenshot, there is a problem with overdrawing of the GUI by the shader output (the first screenshot is captured with the Bilinear set, so no issues there). Also, only some of the shaders work (many others only render black screen, even 1 pass shaders like xbr2).

Then we've tried to switch the build from Wayland with OpenGL to Wayland with GLES and we've found out that the GLES build fails on GL_CLAMP_TO_BORDER not supported by GLES. So we've looked through the Retroarch's code to see how they are handling it and we've found these:
https://github.com/libretro/RetroArch/bl...gl2.c#L754
https://github.com/libretro/RetroArch/bl...l3.c#L2186
https://github.com/libretro/RetroArch/co...1ed495314a

We've done similar #ifdef in ShaderUtilsGL.cpp and we've got the code to build for both GL and GLES. Eventually, after copying some more code from RPRendererOpenGL.cpp to RPRendererOpenGLES.cpp, we've got shaders working under OpenGL ES with similar limitations as for OpenGL (there is even more drawing over the GUI with GLES, but I expect that the source of the problem is the same):


Unfortunately, the holidays are over now and there is no more time left for us to play with this in the foreseeable future (and I am not able to continue myself). Still, it might be useful for anyone, who is going to continue the work, so the code is here:
https://github.com/cuchac/xbmc/commits/r...20-shaders

Feel free to cherry-pick the commits, but there are probably some cosmetic issues with whitespaces etc., so maybe it would be better to do the changes manually.
The first commit is the revert of the revert (nothing interesting there).
The second adds the GLES support and fixes some minor issues.
And the last one fixes more logging issues.

EDIT: Credits go to https://github.com/cuchac.

[MechanicalWhispers]

I did found a small bug: when i control kodi with the controller i don't get the navigation sounds.
When i use the keyboard to navigate the menu's i get a click.
Or is this by design?

Nope, this is a bug. I'll look into it, thanks for reporting.

Is this something that's still being looked into here, as part of Controller fixes #10630 (No navigation sounds for controllers)? https://github.com/xbmc/xbmc/pull/10630

[garbear]

I did found a small bug: when i control kodi with the controller i don't get the navigation sounds.
When i use the keyboard to navigate the menu's i get a click.
Or is this by design?

Nope, this is a bug. I'll look into it, thanks for reporting.

Is this something that's still being looked into here, as part of Controller fixes #10630 (No navigation sounds for controllers)? https://github.com/xbmc/xbmc/pull/10630

Unfortunately Kodi UI sounds are tightly integrated with the keyboard. You can experience this by holding a key and hearing beeps at the rate of operating system key repeats instead of items scrolled in the GUI.

It's possible to add controller sounds, but the system would have to be created from scratch.

[garbear]

GL shaders were disabled a while ago because, while they didn't work on GL, at least they didn't cause problems. But then on macOS the screen was entirely black, so I disabled. Recently, I tried enabling, and now they definitely cause problems even on Linux. So yeah, GL shaders need some love.

@garbear I've just returned from family holidays with a friend who is a developer (unlike me). While our families went to sleep at night, we got an idea to hack a little bit, so we sneaked to a computer and played with the https://github.com/garbear/xbmc/pull/114.

The good news is that it is actually not broken, as we've managed to create a Linux build (Wayland and OpenGL) from your repository (retroplayer-20 branch) with the "reverted revert of the PR114". We added the ShaderPresetsGLSLP.xml and the actual GLSL shaders to game.shader.presets and we've got working shaders on Linux! Even more, while the PR description states that the live preview of the shaders is not supposed to work, it actually worked for us, see the screenshots:


However, as you can see in the second screenshot, there is a problem with overdrawing of the GUI by the shader output (the first screenshot is captured with the Bilinear set, so no issues there). Also, only some of the shaders work (many others only render black screen, even 1 pass shaders like xbr2).

Then we've tried to switch the build from Wayland with OpenGL to Wayland with GLES and we've found out that the GLES build fails on GL_CLAMP_TO_BORDER not supported by GLES. So we've looked through the Retroarch's code to see how they are handling it and we've found these:
https://github.com/libretro/RetroArch/bl...gl2.c#L754
https://github.com/libretro/RetroArch/bl...l3.c#L2186
https://github.com/libretro/RetroArch/co...1ed495314a

We've done similar #ifdef in ShaderUtilsGL.cpp and we've got the code to build for both GL and GLES. Eventually, after copying some more code from RPRendererOpenGL.cpp to RPRendererOpenGLES.cpp, we've got shaders working under OpenGL ES with similar limitations as for OpenGL (there is even more drawing over the GUI with GLES, but I expect that the source of the problem is the same):


Unfortunately, the holidays are over now and there is no more time left for us to play with this in the foreseeable future (and I am not able to continue myself). Still, it might be useful for anyone, who is going to continue the work, so the code is here:
https://github.com/cuchac/xbmc/commits/r...20-shaders

Feel free to cherry-pick the commits, but there are probably some cosmetic issues with whitespaces etc., so maybe it would be better to do the changes manually.
The first commit is the revert of the revert (nothing interesting there).
The second adds the GLES support and fixes some minor issues.
And the last one fixes more logging issues.

EDIT: Credits go to https://github.com/cuchac.

Awesome work! That about concludes the remaining work on shaders. I've prepared a branch for PR against master: https://github.com/xbmc/xbmc/compare/mas...er-shaders

Now all we need is for one of the GSoC participants to PR it.

I'm also doing test builds based on v20.1 and this work.

[KOPRajs]

That about concludes the remaining work on shaders.

I'm afraid there's still a lot of work remaining for the GL shaders. We only tried to solve the build failure for the GLES and then it seemed to be a matter of copy and paste to get the GLES renderer on par with the GL one. Many GLSL shaders are still not working, not to mention the GUI overdrawing issues.

[OmniBlade]

Fairly sure someone mentioned that Kodi wasn't accepted for GSoC this year, so no extra developer time from that it seems

[garbear]

That about concludes the remaining work on shaders.

I'm afraid there's still a lot of work remaining for the GL shaders. We only tried to solve the build failure for the GLES and then it seemed to be a matter of copy and paste to get the GLES renderer on par with the GL one. Many GLSL shaders are still not working, not to mention the GUI overdrawing issues.

If you could get GLES to build, then we could at least PR against master. I think some lines to xbmc/cores/RetroPlayer/shaders/gl are missing in cmake/treedata.

After that it's just a debate of how much we want working before we merge. We might be fine with just Windows and GL shaders at first, with GLES coming in a later pull request.

 

Fairly sure someone mentioned that Kodi wasn't accepted for GSoC this year, so no extra developer time from that it seems

Correct, Kodi wasn't accepted to GSoC 2023 unfortunately. Hopefully next year!

[KOPRajs]

We might be fine with just Windows and GL shaders at first, with GLES coming in a later pull request.

Currently the working state for the GL and the GLES should be identical. At least we haven't encounter any differencies, what worked for us in GL also worked for us in GLES. Many non-working shaders and GUI overdrawing were common to both. The whole code is common, the only difference is the single ifdef for the GL_CLAMP_TO_BORDER. The shaders themselves are supposed to be compatible with both GL and GLES (Retroarch as the source of the shaders ensures that). That is, IF I UNDERSTAND IT CORRECTLY, which I might not :-)
 

I think some lines to xbmc/cores/RetroPlayer/shaders/gl are missing in cmake/treedata.

Not sure what you mean? Were you able to build it? At least the original GL support?

[garbear]

Not sure what you mean? Were you able to build it? At least the original GL support?

 GL support works build I can't get GLES to build. You can see the CI attempts here: https://jenkins.kodi.tv/view/Automation/...oice/1076/

The build error is:
 

Code:

rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::CRPRendererOpenGLES(KODI::RETRO::CRenderSettings const&, KODI::RETRO::CRenderContext&, std::__ndk1::shared_ptr<KODI::RETRO::IRenderBufferPool>): error: undefined reference to 'KODI::SHADER::CShaderPresetGL::CShaderPresetGL(KODI::RETRO::CRenderContext&, unsigned int, unsigned int)'
rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::Render(unsigned char): error: undefined reference to 'KODI::SHADER::CShaderTextureGL::~CShaderTextureGL()'
rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::Render(unsigned char): error: undefined reference to 'KODI::SHADER::CShaderTextureGL::~CShaderTextureGL()'
rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::Render(unsigned char): error: undefined reference to 'KODI::SHADER::CShaderTextureGL::~CShaderTextureGL()'
rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::Render(unsigned char): error: undefined reference to 'KODI::SHADER::CShaderTextureGL::~CShaderTextureGL()'
rp-videorenderers.a(RPRendererOpenGLES.cpp.o):RPRendererOpenGLES.cpp:function KODI::RETRO::CRPRendererOpenGLES::Render(unsigned char): error: undefined reference to 'vtable for KODI::SHADER::CShaderTextureGL'
ld: the vtable symbol may be undefined because the class is missing its key function

[KOPRajs]

GL support works build I can't get GLES to build.

We only have tried it on Linux, no experiences with Android, sorry.