• 1
  • 153
  • 154
  • 155(current)
  • 156
  • 157
  • 165
RetroPlayer Test Builds (updated for Nexus)
(2023-01-20, 18:17)OmniBlade Wrote: What is left to do to add support for cores that require an opengl context such as PPSSPP? I recall another developer wrote a proof of concept version ages ago that seems to have fallen by the wayside?

We might see some action on GL soon. @lrusak dropped a "maybe 21" phrase.
Reply
New round of builds posted. This is based on the final v20 release. Some testing has lead to suggestions (22490 (PR)) and I backported the PR for testing.

https://github.com/garbear/xbmc/releases...0-20230121
Reply
Even better, I did a round of builds today that includes GSoC 2021 Achievements! I've started testing and hopefully we can get this into v21.

As always, https://github.com/garbear/xbmc/releases
Reply
(2023-01-21, 05:52)garbear Wrote: We might see some action on GL soon. @lrusak dropped a "maybe 21" phrase.
Let's hope for the best and keep fingers crossed!
 
(2023-01-24, 00:51)garbear Wrote: Even better, I did a round of builds today that includes GSoC 2021 Achievements!
I see that the OpenGL shaders are listed as disabled. What does it mean? Is it disabled in the code, or is it just because none of the provided build platforms actually support OpenGL?
Reply
(2023-01-24, 01:11)KOPRajs Wrote:
(2023-01-24, 00:51)garbear Wrote: Even better, I did a round of builds today that includes GSoC 2021 Achievements!
I see that the OpenGL shaders are listed as disabled. What does it mean? Is it disabled in the code, or is it just because none of the provided build platforms actually support OpenGL?

Technically, I applied the GSoC commits to make sure they build, then reverted the main "feature" commit, as you can see in the commit history of my v20 builds: https://github.com/garbear/xbmc/commits/retroplayer-20 . So "disabled" is not entirely accurate, the code is compiled out entirely.

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.
Reply
(2023-01-21, 05:52)garbear Wrote:
(2023-01-20, 18:17)OmniBlade Wrote: What is left to do to add support for cores that require an opengl context such as PPSSPP? I recall another developer wrote a proof of concept version ages ago that seems to have fallen by the wayside?

We might see some action on GL soon. @lrusak dropped a "maybe 21" phrase.

OpenGL 3D acceleration would be so awesome! The major game related feature then missing is a games database/library as discussed in -> https://forum.kodi.tv/showthread.php?tid=357018
Reply
I posted another round of builds, and this round is special! It includes the new savestate manager and all my fixes in all their glory. Testing of savestates is appreciated, as we're trying to get them rock solid for the v20.1 release.

https://github.com/garbear/xbmc/releases
Reply
(2023-01-25, 21:03)RockerC Wrote: The major game related feature then missing is a games database/library as discussed in ...

And the shader support for GL/GLES!  Wink
Needed for shaders in LibreELEC, Android and Linux in general.
Reply
@garbear I'm not sure where is the right place to discuss this, feel free to move this post. It is affecting more then a single Github repo.

1. I'm going to try to tune the buttonmaps for the Sega Genesis emulators (genplus, genplus-wide, picodrive) and also to create the multitaps and the 3 button controller profiles as discussed here (https://github.com/kodi-game/game.libret.../issues/11).
Is there a common place to get icons for the 3 new controller profiles? Who created current artwork for the other controllers?

2. While digging through the topology and the button mapping, I've come to a conclusion that currently we have "A"<->"B" and "X"<->"Y" swapped for both NES and SNES (in all emulators). We are mapping "A"->"A", but the original NES controller has "B" on the left and "A" on the right, the opposite of Kodi's default controller based on Xbox.

So the buttonmap.xml for e.g. the Nestopia should be changed from this:
Code:
<feature name="a" mapto="RETRO_DEVICE_ID_JOYPAD_A"/>
<feature name="b" mapto="RETRO_DEVICE_ID_JOYPAD_B"/>

To this:
Code:
<feature name="a" mapto="RETRO_DEVICE_ID_JOYPAD_B"/>
<feature name="b" mapto="RETRO_DEVICE_ID_JOYPAD_A"/>

And "X"<->"Y" should be swapped for the SNES as well.

This should be fixed for all the NES emulators and all the SNES emulators (others might be affected as well, but NES and SNES are the most obvious). I don't like the idea of forking every of those repos and creating a lot of PRs just to make this tiny little change. Is there a way for you to fix this more easily with direct access to the repos?
Reply
I've seen a lot of references to openemu.org in the Genesis 6 button controller profile. Is there a way to export the profiles automatically? I've found out that there are even translations for every controller. Is it done manually?

EDIT: Also I can see that the branding needs to be removed from the icon?
Reply
(2023-02-03, 14:14)KOPRajs Wrote: Is there a common place to get icons for the 3 new controller profiles? Who created current artwork for the other controllers?

We have so much controller artwork because, in 2017, the largest wildfire (until 2018, that is) in California burned my neighborhood down. I had nothing else to do living in hotels so I spent 3 months creating the artwork, descriptions and buttonmaps in the controller topology project repo. It was a lot of searching, researching, reading and photoshopping.
(2023-02-03, 14:14)KOPRajs Wrote: 2. While digging through the topology and the button mapping, I've come to a conclusion that currently we have "A"<->"B" and "X"<->"Y" swapped for both NES and SNES (in all emulators). We are mapping "A"->"A", but the original NES controller has "B" on the left and "A" on the right, the opposite of Kodi's default controller based on Xbox.

You've discovered the fundamental dichotomy in controller mapping. What is actually happening is that two cultures have evolved different ways to lay out buttons on a controller.

You have the Japanese layout, as can be seen in the SNES controller.

You also have the Western layout, as can be seen in the Xbox controller.

There are also two ways to map controllers:
 
  • The physical mapping, which maps A on japanese controllers to B on western controllers, because these buttons are in the same physical spot.
  • The logical mapping, which maps A on japanese controllers to A on western controllers, because they both "logically" are the "confirm" / "main action" button

RetroArch uses the physical mapping. The "reference" controller for face buttons is the SNES controller. Everything in libretro is a physical mapping to the SNES controller.

If you want to solve the problem for reals, we need a preference in Kodi: Do you want the logical mapping or the physical mapping. Visually, this can be viewed as Logical = A -> A and Physical = A -> B.

I have seen people prefer both. I prefer the logical mapping, because I'm used to the western layout. I observed @natethomas rock at Super Mario, but only after we swapped the buttons because he grew up and was visual-motorly adapted to the Japanese layout.

Does this offer more insight into the challenges we need to overcome?
(2023-02-03, 15:04)KOPRajs Wrote: I've seen a lot of references to openemu.org in the Genesis 6 button controller profile. Is there a way to export the profiles automatically? I've found out that there are even translations for every controller. Is it done manually?

OpenEmu is BSD-licensed. This means we can curate their artwork under the same license. I have done so: https://github.com/kodi-game/OpenEmuControllerArt

It may need to be updated or modernized, as you can see I curated last in December 2017 (about 3 days before the fire).
Quote:EDIT: Also I can see that the branding needs to be removed from the icon?

Yup, but this isn't hard in photoshop. Fortunately the entire Team stepped up and did the branding removal for me once I curated the images.
Reply
(2023-02-04, 05:50)garbear Wrote: The logical mapping, which maps A on japanese controllers to A on western controllers, because they both "logically" are the "confirm" / "main action" button

I don't agree with this. E.g. In Sega Genesis the main button is usually the "C". The game author mapped the keys with having some basic ergonomy in mind. You don't want to have your "most important button" like the fire action to be the most far away from your fingers. Some games rely on pretty heavy button combos which can't be done with the swapped controls. 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. In fact, we already do this for several emulators, see the Nintendo 64 mapping (or Playstation), we don't map "A"->"A" in these, rather we are trying to preserve the physical mapping and we map "A"->"B" already there.

So please consider switching the default mapping at least for NES and SNES to "A"->"B" and "X"->"Y". I will try to take care of the Sega Genesis. There are probably other affected emulators (but not all of them), but I can't speak for emulators that I don't actually use. If individuals want to change the mapping, they still can, but the default should preserve the original layout and ergonomy. The new users wouldn't even know that the controls are swapped if they haven't played the original game before.
 
(2023-02-04, 05:50)garbear Wrote: Yup, but this isn't hard in photoshop. Fortunately the entire Team stepped up and did the branding removal for me once I curated the images.

So I went to Google, found some image and tried my best:
Image

I will update the PR later today (with the layout and the mask as well). Google have found the source image on multiple websites across the internet (like 20 or more sites) so I don't know who is the original author of the image. Is it ok to use such widely spread image as the source?

I've done the logo removal, transparency, shadow and the background gradient to match the other Genesis controller.
Reply
Can anyone point me in the right direction for how to build kodi with all of the retroplayer patches in libreelec. I do know my way around git but if there was something out there that could confidently get me started in building i'd happily post builds when there's updates.
Reply
(2023-02-04, 11:17)sunlollyking Wrote: Can anyone point me in the right direction for how to build kodi with all of the retroplayer patches in libreelec. I do know my way around git but if there was something out there that could confidently get me started in building i'd happily post builds when there's updates.

You have 2 options:

1. You can create a patch from the LibreELEC's version of Kodi (currently the Nexus-20.0) to the Retroplayer and place the patch file to packages/mediacenter/kodi/patches/.

2. Or you can change the source for the Kodi package in packages/mediacenter/kodi/package.mk.

You can get some inspiration here, but this repo is probably not updated to the current version:
https://github.com/garbear/LibreELEC.tv/...layer-10.0
https://github.com/garbear/LibreELEC.tv/...992ac4d27d
Reply
@sunlollyking I can help you with LibreELEC builds with RetroPlayer patches. I used to do them myself but haven't recently. I can start again if it'd be useful for you. These days I'm doing a new build (and new patches) every few days.
Reply
  • 1
  • 153
  • 154
  • 155(current)
  • 156
  • 157
  • 165

Logout Mark Read Team Forum Stats Members Help
RetroPlayer Test Builds (updated for Nexus)16