•   
  • 1
  • 110
  • 111
  • 112(current)
  • 113
  • 114
  • 150
  •   
RetroPlayer Test Builds (updated for Leia)
(2017-08-06, 07:18)garbear Wrote: 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!
"PPC is too slow, your CPU has no balls to handle HD content." ~ Davilla
"Maybe it's a toaster. Who knows, but it has nothing to do with us." ~ Ned Scott
Reply
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
Reply
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.
Reply
(2017-08-07, 15:57)enen92 Wrote: -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.
Reply
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?
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
(2017-08-07, 15:57)enen92 Wrote: 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.

(2017-08-07, 15:57)enen92 Wrote: -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?

(2017-08-07, 15:57)enen92 Wrote: -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.

(2017-08-07, 15:57)enen92 Wrote: -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.

(2017-08-07, 15:57)enen92 Wrote: -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.
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
(2017-08-07, 23:11)garbear Wrote: 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
Reply
(2017-08-08, 06:20)natethomas Wrote:
(2017-08-07, 23:11)garbear Wrote: 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:

Image

or for the decoration of the gameosd itself:

Image

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).
Reply
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?
Reply
(2017-08-12, 23:42)d3mncln3r Wrote: 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.
"PPC is too slow, your CPU has no balls to handle HD content." ~ Davilla
"Maybe it's a toaster. Who knows, but it has nothing to do with us." ~ Ned Scott
Reply
(2017-08-12, 23:42)lrusak Wrote:
(2017-08-12, 23:42)d3mncln3r Wrote: 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.
Reply
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.
Reply
(2017-08-13, 00:02)nihilisticEevee Wrote: 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.
"PPC is too slow, your CPU has no balls to handle HD content." ~ Davilla
"Maybe it's a toaster. Who knows, but it has nothing to do with us." ~ Ned Scott
Reply
(2017-08-13, 00:11)lrusak Wrote:
(2017-08-13, 00:02)nihilisticEevee Wrote: 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.
Reply
(2017-08-13, 00:22)nihilisticEevee Wrote:
(2017-08-13, 00:11)lrusak Wrote:
(2017-08-13, 00:02)nihilisticEevee Wrote: 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.
"PPC is too slow, your CPU has no balls to handle HD content." ~ Davilla
"Maybe it's a toaster. Who knows, but it has nothing to do with us." ~ Ned Scott
Reply
  •   
  • 1
  • 110
  • 111
  • 112(current)
  • 113
  • 114
  • 150
  •   
 
Thread Rating:
  • 16 Vote(s) - 4.56 Average



Logout Mark Read Team Forum Stats Members Help
RetroPlayer Test Builds (updated for Leia)4.5616