[lrusak]

New test builds uploaded. Featuring Nearest Neighbor filtering on Windows thanks to vel0city, and an improved scaling mode and view mode selector in the Game OSD. Also I've added around 40 controller profiles in preparation for the upcoming player manager.

You're the man!

[enen92]

Tested it last night on OSX, outstanding work as usual. Thanks to vel0city for the nearest neighbour filter now retroplayer looks as sharp as retroarch.
Keyboard is broken somehow but I guess it is a known issue according to the retroplayer UI thread.
A few questions:

-is mouse support planned or implemented? Right now it activates the gameosd dialog everytime it is triggered. Probably not implemented yet.

-launching IARL scummvm games from the addon by choosing scummvm as the emulator crashes Kodi. This is probably an error in IARL since the game starts fine from the file manager after the download.

-is game overlay support planned for retroplayer? I have no idea how that is implemented it retroarch but the Kodi version could use some simple python addons that manipulate the gameosd dialog.

-Is there any updated place we can check the current list of supported libretro cores in retroarch? They seem to have now some experimental cores (commodore64 for instance) that are not listed on their wiki.

Best regards

Enviado do meu A0001 através de Tapatalk

[fetzerch]

I've fixed mouse support yesterday for ScummVM and Dosbox. The buttonmap needed an update after recent changes to game.libretro (see https://github.com/kodi-game/game.libret...l/11/files). It should work again in the next testbuild, but you can also just apply the changes to the 2 buttonmap.xml files.

[natethomas]

-is game overlay support planned for retroplayer? I have no idea how that is implemented it retroarch but the Kodi version could use some simple python addons that manipulate the gameosd dialog.

If I remember right, a while back overlays were considered just another shader in retroarch, along with the all the other elements that made the image look like an old CRT.

[garbear]

Shader support is happening because we have a collection of shaders and code (in RetroArch) that shows how to use them. Can you post something similar for overlays?

[garbear]

Keyboard is broken somehow but I guess it is a known issue according to the retroplayer UI thread.

I'm redoing keyboard support to allow mapping joystick buttons to keyboard keys. This will be submitted in a PR before the Player Window hits, ETA several weeks.

-is mouse support planned or implemented? Right now it activates the gameosd dialog everytime it is triggered. Probably not implemented yet.

Ditto mouse support.

Currently, we just use the Fullscreen Video code - moving the mouse brings up the OSD. What behavior should the mouse have when it's not captured by the game?

-launching IARL scummvm games from the addon by choosing scummvm as the emulator crashes Kodi. This is probably an error in IARL since the game starts fine from the file manager after the download.

I'll reproduce and fix this during the downtime after I submit the Player Window pull request while I'm waiting the week or two for it to be reviewed and tested. I've added it to the list of known bugs in the OP release notes.

-is game overlay support planned for retroplayer? I have no idea how that is implemented it retroarch but the Kodi version could use some simple python addons that manipulate the gameosd dialog.

Can you investigate how this works in RetroArch or other emulators? I can't implement overlays from scratch but I can adapt an existing system. I'll evaluate python support when I have a better idea of what overlays entails.

-Is there any updated place we can check the current list of supported libretro cores in retroarch? They seem to have now some experimental cores (commodore64 for instance) that are not listed on their wiki.

The source of all source is GitHub. Start there, and if you find a new core we can support it.

[natethomas]

Shader support is happening because we have a collection of shaders and code (in RetroArch) that shows how to use them. Can you post something similar for overlays?

Well, there's documentation about how to use them. https://github.com/libretro/RetroArch/wi...figuration

Not sure if that's good enough, but the author of the page might have more info.

edit: Also, collections of overlays. Strangely in two different locations?
https://github.com/libretro/overlay-borders
https://github.com/libretro/common-overlays

[enen92]

Shader support is happening because we have a collection of shaders and code (in RetroArch) that shows how to use them. Can you post something similar for overlays?

Well, there's documentation about how to use them. https://github.com/libretro/RetroArch/wi...figuration

Not sure if that's good enough, but the author of the page might have more info.

edit: Also, collections of overlays. Strangely in two different locations?
https://github.com/libretro/overlay-borders
https://github.com/libretro/common-overlays

Yes, they use the term "overlay" for either the controls in touch enabled devices:



or for the decoration of the gameosd itself:



Both of them are .cfg files that define the images position and their behaviour as Nate explained above.

My question was more directed to the overlay-borders (eg: https://github.com/libretro/overlay-bord...b_Wars.png) since a discussion on the GameOSD dialog is taking place right now. They seem to be just decoration of the window itself (like a frame sorounding the videocontrol). IMO they are too simple that can be made as addons (either python by manipulating the gameosd xml or just addons that replace the gameosd by another windowxml). Also the kodi skinning engine is probably much more advanced than the one available in retroarch so this approach would allow developers much more freedom to develop custom overlays in the form of addons. On a side note, I think your approach to the gameosd is also perfect since you decided to go with a new window instead of using the videoosd (and as a result you dropped the progress bar and all the other controls on the window). If overlays are considered, the less controls you have on the window..the better.

Regarding mouse behaviour I think your approach is correct @garbear. If the game does not support mouse input it should pause the game and bring up the gameosd window (comment/question was regarding dosbox and scummvm but fetzerch explained the error).

[d3mncln3r]

hey, there is probably an easy answer to this problem, but when I'm playing a game (Nestopia) using 8bitdo controller, the directional pads bring up the information overlay when touched. It used to initiate rewind, but I disabled that feature to prevent this, but it . So I think its interpreting D-pads on a navigation level and emulator level. When I use the xbox wireless controller this doesn't happen, the game plays fine. I've tried running the input config wizard using the 8bitdo controller with "Kodi" and "NES" controller options. I'm running Milhouse build #0809, 10-Aug-2017. Is there somewhere I can tell the system not to listen to the 8bitdo controller for navigation commands?

[lrusak]

hey, there is probably an easy answer to this problem, but when I'm playing a game (Nestopia) using 8bitdo controller, the directional pads bring up the information overlay when touched. It used to initiate rewind, but I disabled that feature to prevent this, but it . So I think its interpreting D-pads on a navigation level and emulator level. When I use the xbox wireless controller this doesn't happen, the game plays fine. I've tried running the input config wizard using the 8bitdo controller with "Kodi" and "NES" controller options. I'm running Milhouse build #0809, 10-Aug-2017. Is there somewhere I can tell the system not to listen to the 8bitdo controller for navigation commands?

It's a bug. I'm pretty sure garbear knows about it.

[d3mncln3r]

hey, there is probably an easy answer to this problem, but when I'm playing a game (Nestopia) using 8bitdo controller, the directional pads bring up the information overlay when touched. It used to initiate rewind, but I disabled that feature to prevent this, but it . So I think its interpreting D-pads on a navigation level and emulator level. When I use the xbox wireless controller this doesn't happen, the game plays fine. I've tried running the input config wizard using the 8bitdo controller with "Kodi" and "NES" controller options. I'm running Milhouse build #0809, 10-Aug-2017. Is there somewhere I can tell the system not to listen to the 8bitdo controller for navigation commands?

It's a bug. I'm pretty sure garbear knows about it.

ah ok, cool. Thought it was a setting I missed in the config or something, thanks.

[nihilisticEevee]

I know you(garbear) said there would be advanced video options later, but i wanted to ask. Will there be a hard gpu sync option? I love the option in retroarch as it helps with input lag and is why i use retroarch as often as possible.

I know this is prob. long off(if at all) but i want to bring it so it can be planned for, rather than having to rewrite bunch of stuff in include it later on.

[lrusak]

I know you(garbear) said there would be advanced video options later, but i wanted to ask. Will there be a hard gpu sync option? I love the option in retroarch as it helps with input lag and is why i use retroarch as often as possible.

I know this is prob. long off(if at all) but i want to bring it so it can be planned for, rather than having to rewrite bunch of stuff in include it later on.

This will require the a retroplayer video renderer as it uses sync/fencing to make sure the rendering is a good as possible.

See, https://github.com/libretro/RetroArch/wi...erformance

They talk about drm/kms also which is linux specific. This is apparently the best way to run RetroArch. Kodi can run on drm/kms (v18 only) and I have a special LibreELEC build that uses it (for x86 hardware). If you are interested in testing that I can post a link.

[nihilisticEevee]

I know you(garbear) said there would be advanced video options later, but i wanted to ask. Will there be a hard gpu sync option? I love the option in retroarch as it helps with input lag and is why i use retroarch as often as possible.

I know this is prob. long off(if at all) but i want to bring it so it can be planned for, rather than having to rewrite bunch of stuff in include it later on.

This will require the a retroplayer video renderer as it uses sync/fencing to make sure the rendering is a good as possible.

See, https://github.com/libretro/RetroArch/wi...erformance

They talk about drm/kms also which is linux specific. This is apparently the best way to run RetroArch. Kodi can run on drm/kms (v18 only) and I have a special LibreELEC build that uses it (for x86 hardware). If you are interested in testing that I can post a link.

Thanks for the offer but i want to wait for retroplayer to be more mature before i install it my windows pc.

[lrusak]

I know you(garbear) said there would be advanced video options later, but i wanted to ask. Will there be a hard gpu sync option? I love the option in retroarch as it helps with input lag and is why i use retroarch as often as possible.

I know this is prob. long off(if at all) but i want to bring it so it can be planned for, rather than having to rewrite bunch of stuff in include it later on.

This will require the a retroplayer video renderer as it uses sync/fencing to make sure the rendering is a good as possible.

See, https://github.com/libretro/RetroArch/wi...erformance

They talk about drm/kms also which is linux specific. This is apparently the best way to run RetroArch. Kodi can run on drm/kms (v18 only) and I have a special LibreELEC build that uses it (for x86 hardware). If you are interested in testing that I can post a link.

Thanks for the offer but i want to wait for retroplayer to be more mature before i install it my windows off the pc.

Sure, but just an FYI LibreELEC can be installed and run off a USB stick.