What do you think the likelyhood is of RetroPlayer being merged into the GA branch of Kodi Krypton (v17)? I know the Kodi team is trying to release branches a lot faster, and was just wondering if that has any bearing on this project.
18 is more likely. I'm removing retroplayer and augmenting videoplayer to handle the raw pixel formats that games use. The awesome thing is that we get video and audio decoding for free for the GameStream add-on.
For gaming purposes, VideoPlayer has 3 stages: Input, decoding, and rendering.
Input - routing the AV streams from the Game API to VideoPlayer. I finished this part 2 weeks ago.
Decoding - By using VideoPlayer, this is already done for h264, so GameStream is ready to be tested today. Libretro cores use raw pixel data, so this requires a pixel conversion "codec" to a format the renderer supports.
Rendering - This requires no changes, but can be optimized to remove the need for pixel conversion.
Yesterday I rebased RetroPlayer on master with the controller input PR merged. You can see the current patch in my
retroplayer-17alpha1 branch. It's compile-tested, but needs more work (mostly the pixel conversion "codec") before test builds will be ready.
Controller input has been merged, which means the RetroPlayer patch has gone from 30,000 lines to 12,000 lines, a 60% reduction in code size. This should accelerate development, not to mention the boost I get from knowing RetroPlayer is more than half merged now. Test builds based on 17 may appear soon after we start monthly release cycles again.
Really great to hear! The test build I installed looked already promising, but seems like there is still a lot to do.
Anyway I'm looking forward to the integration of games into kodi! Thanks for all your work
Hopefully the dolphin emu will be available as a libretro core as well then. As well as support for the wireless Xbox one dongle within the Linux kernel
BTW if I remember correctly aren't there on going changes to the video playback? I think I've read about a whole new replacement of kodis video player component. Hope those changes are already in that new branch so it won't break everything :S
The video playback changes have all been merged to master. My work is based on all the excellent work done there.
Will performance on RetroPlayer be comparable to RetroPie on the Raspberry Pi?
Well, we wont know until we measure
Realize that you're running a full-blown media center, so RetroPlayer is guaranteed to be a heavier load. That said, when the gui is hidden, and if all services are disabled, performance might be comparable.
Is there still intention to support the cores the require an OpenGL context to draw to (N64, PPSSPP, Reicast?) at some point?
(2016-03-15, 00:37)garbear Wrote: [ -> ]Libretro cores use raw pixel data, so this requires a pixel conversion "codec" to a format the renderer supports.
Rendering - This requires no changes, but can be optimized to remove the need for pixel conversion.
Does all libretro cores use the same type of raw pixel data and therefor require the same conversion or does different libretro cores require different conversions?
(2016-03-15, 11:16)OmniBlade Wrote: [ -> ]Is there still intention to support the cores the require an OpenGL context to draw to (N64, PPSSPP, Reicast?) at some point?
I still plan to chime in again and help getting libretro-gl cores to work.
(2016-03-15, 14:25)RockerC Wrote: [ -> ] (2016-03-15, 00:37)garbear Wrote: [ -> ]Libretro cores use raw pixel data, so this requires a pixel conversion "codec" to a format the renderer supports.
Rendering - This requires no changes, but can be optimized to remove the need for pixel conversion.
Does all libretro cores use the same type of raw pixel data and therefor require the same conversion or does different libretro cores require different conversions?
libretro supports the following pixel formats:
Code:
enum retro_pixel_format
{
// 0RGB1555, native endian. 0 bit must be set to 0.
// This pixel format is default for compatibility concerns only.
// If a 15/16-bit pixel format is desired, consider using RGB565.
RETRO_PIXEL_FORMAT_0RGB1555 = 0,
// XRGB8888, native endian. X bits are ignored.
RETRO_PIXEL_FORMAT_XRGB8888 = 1,
// RGB565, native endian. This pixel format is the recommended format to use if a 15/16-bit format is desired
// as it is the pixel format that is typically available on a wide range of low-power devices.
// It is also natively supported in APIs like OpenGL ES.
RETRO_PIXEL_FORMAT_RGB565 = 2,
};
(2016-03-15, 16:37)a1rwulf Wrote: [ -> ] (2016-03-15, 11:16)OmniBlade Wrote: [ -> ]Is there still intention to support the cores the require an OpenGL context to draw to (N64, PPSSPP, Reicast?) at some point?
I still plan to chime in again and help getting libretro-gl cores to work.
I'll ping you when the videoplayer work is stable enough to build hardware rendering on
(2016-03-15, 21:37)garbear Wrote: [ -> ]I'll ping you when the videoplayer work is stable enough to build hardware rendering on
Sounds good - I know I'm not around a lot, but if there's anything you need, you can ping me anytime and I'll see how I can manage to help.
Will you be able to browse Kodi GUI movie library etc using gaming controllers on retroplayer?
(2016-03-17, 15:22)the_bo Wrote: [ -> ]Will you be able to browse Kodi GUI movie library etc using gaming controllers on retroplayer?
You already can in Krypton nightly builds.
Kodi supports game controllers since ages