[Bstrdsmkr]

Netplay doesn't have to be baked into the libretro core itself - it's a frontend feature.

RetroArch (the 'official' libretro frontend) supports netplay just fine. It uses a rollback scheme similar to GGPO. Netplay in RetroArch works by making use of the 'rewinding' feature that has been implemented in most libretro ports (ie. savestate serialization).

So it's possible at least for XBMC's libretro player to offer something similar to that. Netplay is limited to two players at the moment though.

Also - one of our porters - lifning - ported a really neat Game Boy emulator to libretro - tgb-dual - its unique selling point is that you can do splitscreen multiplayer (and more) as if it were a console instead of a handheld. That could be fun for Tetris multiplayer sessions.

I'm a little muddy (mainly because I failed to study the whole libreto and etc architecture) but does that mean Team-xbmc would have to implement netplay support? If so, that's unfortunate as their ticket is already quite full lol

[squarepusher]

Netplay doesn't have to be baked into the libretro core itself - it's a frontend feature.

RetroArch (the 'official' libretro frontend) supports netplay just fine. It uses a rollback scheme similar to GGPO. Netplay in RetroArch works by making use of the 'rewinding' feature that has been implemented in most libretro ports (ie. savestate serialization).

So it's possible at least for XBMC's libretro player to offer something similar to that. Netplay is limited to two players at the moment though.

Also - one of our porters - lifning - ported a really neat Game Boy emulator to libretro - tgb-dual - its unique selling point is that you can do splitscreen multiplayer (and more) as if it were a console instead of a handheld. That could be fun for Tetris multiplayer sessions.

I'm a little muddy (mainly because I failed to study the whole libreto and etc architecture) but does that mean Team-xbmc would have to implement netplay support? If so, that's unfortunate as their ticket is already quite full lol

It's definitely not something that is handled in each libretro core specifically - no specific netplay code has to be written in the emulator or game port. It's core-agnostic, and so is handled by the frontend. The advantage of this is that you can implement netplay once in your frontend and not have to think about it for each new 'libretro port' you make - as long as there is some local way to do 2-player multiplayer gaming in an emu/game, and as long as the libretro port implements 'rewind' (ie. savestate serialization), it should be netplay compatible by default.

Also - I imagine XBMC has a far more fleshed out network sublayer than RetroArch, so if anything, just piggybacking off savestate serialization and hooking into XBMC's networking model should be pretty simple. And when in doubt, you could always look at our netplay code and either copy it wholesale or just take it in a different direction.

Anyway, it's probably more prudent making sure that things are running stable and smoothly before piling on the features

[Bstrdsmkr]

Ahhh that makes much more sense than what I had arrived at in my head (a per Rom implementation).

Obviously I wouldn't try to demand features or anything. It's just fun to brain storm and imagine possibilities

[King Dude]

Obviously I wouldn't try to demand features or anything. It's just fun to brain storm and imagine possibilities

Same here, man.

[paendorz]

Ok, grabbed the source and compiled it. (Win8/VS2012)

There seems to be some audio delay (about +1 sec or something like that) and the genesis-plus libretro port shows some weird colors.

But anyway, this is freaking awesome.

I'd be happy to help with some testing if needed. I'd shoot garbear a PM to let him know but afaik, Github doesnt have a proper messaging system.

Also, any chance this will be eventually merged into the main branch?

[ghostelement]

Another thought, with XBMC for Android we can launch other Android apps (such as games) directly from XBMC. So any games library could work (in theory) be made to work with libretro+ROMs and Android games. And yes, thegamesdb.net looks like they've got us covered for scraping

Excellent news!

[Ned Scott]

Also, any chance this will be eventually merged into the main branch?

A very high chance, seeing as just about everyone on Team XBMC reacted with the same "holy crap, that's freaking awesome" kind of response :D

[squarepusher]

Ok, grabbed the source and compiled it. (Win8/VS2012)

There seems to be some audio delay (about +1 sec or something like that) and the genesis-plus libretro port shows some weird colors.

RGB565 support for textures might not be available in XBMC - it is generally assumed by now that the libretro frontend supports either XRGB8888 (for 32bit color mode) or RGB565 (for 16bit color mode). A libretro port can choose either RGB565, XRGB8888 or RGB1555 as its preferred color format (the latter is deprecated though and will mostly always lead to color conversion, so it's discouraged to use this as anything other than a last resort). Catering to all of them is usually not done - if the preferred format 'fails' (ie. RGB565 or XRGB8888), then it would resort to RGB1555 - and you'd have to convert colors in your libretro frontend.

If RGB565 support is not available, you can 'revert' back to RGB1555 (the way it was before) by compiling - say - Genesis Plus GX without FRONTEND_SUPPORTS_RGB565 defined.

Be warned though - the entire reason we made this switch to RGB565 was because RGB565 is a native image/texture format on Android and other lower-specced systems - forcing RGB1555 on it led to internal color conversion and dreadful performance.

If the best performance possible is not a priority and XBMC runs in 32bit mode for its context and textures, you could resort to color conversion - maister made SSE-optimized code which could be reused if needed (and NEON possibly later for ARMv7a+ systems). To do that, you would have to implement your 'environ callback' to set the color format in such a way that RGB565 and/or XRGB888 are not supported if they're queried by the libretro frontend - then it would default to RGB1555.

If you guys need any help sorting this out me and maister would be glad to help.

As for audio delay - it smacks of A/V sync issues. Our input/audio/video drivers are optimized for games/emus - your drivers are probably optimized with movies in mind. We ran into similar issues when we tried to port FFmpeg/mplayer to libretro - we found that our frontend drivers were not really suitable for movies and were too game-specific - the reverse might be the case here. I guess what you could try in the interim is to fiddle around with audio/video latency - if that doesn't work you might have to look into making XBMC's video/audio drivers more suitable for realtime usecases.

Other things that could contribute to audio delay/latency on the audio front could be the audio resampler, float to int/integer to float conversion, and the like. Maister is pretty good at audio and has written Altivec/SSE/NEON-optimized resamplers and audio conversion routines.

[paendorz]

If RGB565 support is not available, you can 'revert' back to RGB1555 (the way it was before) by compiling - say - Genesis Plus GX without FRONTEND_SUPPORTS_RGB565 defined.

Tried that, same result. Maybe I missed something.

Cores I tested so far:

NES (both fceu-next and bnes) and GBC (gambatte) are working fine:



GBA (vba-next) and Sega Genesis (Genesis-Plus-GX) are not:

[squarepusher]

Gambatte uses XRGB8888 (32bit color format) as its preferred color format so no surprise

The libretro frontend for XBMC is probably not handling RGB1555 properly either - only XRGB8888.

The problem here is that your libretro frontend (ie. the XBMC libretro player) is not properly handling RGB565 and RGB1555 color formats. Either you set the texture format to RGB565 if the environ callback for setting the color fomat is triggered and it sets RGB565, or failing that - you do custom color conversion in the libretro frontend (the XBMC libretro player) - converting it to XRGB8888 if it isn't already XRGB8888.

[paendorz]

Gambatte uses XRGB8888 (32bit color format) as its preferred color format so no surprise

The libretro frontend for XBMC is probably not handling RGB1555 properly either - only XRGB8888.

The problem here is that your libretro frontend (ie. the XBMC libretro player) is not properly handling RGB565 and RGB1555 color formats. Either you set the texture format to RGB565 if the environ callback for setting the color fomat is triggered and it sets RGB565, or failing that - you do custom color conversion in the libretro frontend (the XBMC libretro player) - converting it to XRGB8888 if it isn't already XRGB8888.

Tried to force the format and nothing so I guess color conversion it is.

Dunno the first thing about it but I've always wanted to get into this side of programming and the timing feels right.

[King Dude]

Again with my multiplayer support idea,

Suppose there was a parent server system with P2P "children" assistance? The main server(s) would be maintained by XBMC staff and would power the important processes as well as act like a control center to enforce banning and such. The P2P would assist this head server system by handling the lower-priority processes, with supervision of the head processor.

[malte]

Also, any chance this will be eventually merged into the main branch?

A very high chance, seeing as just about everyone on Team XBMC reacted with the same "holy crap, that's freaking awesome" kind of response

Wow, looks like I missed one of the most interesting threads of the last weeks...

Are there already any plans about future integration of all this? Sounds like there will be sort of a db and scraping like we have for the video library. So, I guess there will be soon the day when the current gaming addons in XBMC become obsolete, right?

In the meantime, will it make sense (and will it be possible) to add support for the new XBMC emulator core from the addons?

[jompan87]

Any recent progress on this? I see garbears commits is now 3 months old

Anyhow, a joy to see this finaly beeing implented.

Much apprichiated, kudos to garbear and anyon else innvolved!

[Ned Scott]

Any recent progress on this? I see garbears commits is now 3 months old

Anyhow, a joy to see this finaly beeing implented.

Much apprichiated, kudos to garbear and anyon else innvolved!

At the very least, there won't be much progress on it until after Frodo is released since most of the devs are busy with that. On top of that, garbear has been busy in his own life and hasn't even been seen much on the forums or IRC, let alone coding.

However, since it is open source, anyone can take a crack at it themselves or get in touch with garbear to see what they might be able to help with.