+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: Game support (https://forum.kodi.tv/forumdisplay.php?fid=292)
+--- Thread: RetroPlayer Test Builds (updated for Nexus) (/showthread.php?tid=173361)
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-02-05
(2023-02-04, 10:32)KOPRajs Wrote: 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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-02-05
(2023-02-05, 05:57)garbear Wrote: 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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-02-10
@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!
RE: RetroPlayer Test Builds (updated for Nexus) - zachmorris - 2023-02-10
Can confirm the same issue in linux and OSX. Nothing will launch and the log shows no suitable players available (even though there are).
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-02-13
(2023-02-10, 14:44)KOPRajs Wrote: 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.
(2023-02-10, 14:44)KOPRajs Wrote: 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.
(2023-02-10, 14:44)KOPRajs Wrote: 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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-11
(2023-01-24, 01:54)garbear Wrote: 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/blob/master/gfx/drivers/gl2.c#L754
https://github.com/libretro/RetroArch/blob/master/gfx/drivers/gl3.c#L2186
https://github.com/libretro/RetroArch/commit/3346cd23c03b539e7653ddead89adb1ed495314a
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/retroplayer-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.
RE: RetroPlayer Test Builds (updated for Krypton) - MechanicalWhispers - 2023-03-14
(2016-10-23, 23:07)garbear Wrote: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(2016-10-23, 22:38)Woerd88 Wrote: 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.
RE: RetroPlayer Test Builds (updated for Krypton) - garbear - 2023-03-21
(2023-03-14, 13:33)MechanicalWhispers Wrote:(2016-10-23, 23:07)garbear Wrote: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(2016-10-23, 22:38)Woerd88 Wrote: 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.
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.
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-21
(2023-03-11, 11:20)KOPRajs Wrote:(2023-01-24, 01:54)garbear Wrote: 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/blob/master/gfx/drivers/gl2.c#L754
https://github.com/libretro/RetroArch/blob/master/gfx/drivers/gl3.c#L2186
https://github.com/libretro/RetroArch/commit/3346cd23c03b539e7653ddead89adb1ed495314a
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/retroplayer-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/master...garbear:retroplayer-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.
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-22
(2023-03-21, 00:38)garbear Wrote: 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.
RE: RetroPlayer Test Builds (updated for Nexus) - OmniBlade - 2023-03-22
Fairly sure someone mentioned that Kodi wasn't accepted for GSoC this year, so no extra developer time from that it seems
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-22
(2023-03-22, 12:56)KOPRajs Wrote:(2023-03-21, 00:38)garbear Wrote: 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.
(2023-03-22, 22:22)OmniBlade Wrote: 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!
RE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-23
(2023-03-22, 23:28)garbear Wrote: 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 :-)
(2023-03-22, 23:28)garbear Wrote: 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?
RE: RetroPlayer Test Builds (updated for Nexus) - garbear - 2023-03-25
(2023-03-23, 01:08)KOPRajs Wrote: 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/job/BuildMulti-Choice/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 functionRE: RetroPlayer Test Builds (updated for Nexus) - KOPRajs - 2023-03-26
(2023-03-25, 23:04)garbear Wrote: GL support works build I can't get GLES to build.
We only have tried it on Linux, no experiences with Android, sorry.