Kodi Community Forum

Full Version: Cutting down on options
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Now that the freezing issue has been resolved, retroplayer is working fairly awesomely. I'm just throwing out a suggestion. What if we only shipped with a maximum of two emulators per platform, rather than 5 to 7? My assumption is that people simply don't have the inclination to go look up what the best emulator is, and they certainly won't try out multiple emulators, if the first one breaks a lot.

So why not do the work for them, identify two emulators least likely to break (categories:"most accurate" for powerful machines and "fastest" for embedded and low power machines), and then give them the option of selecting between those two?

How we identify the best emulators could be a bit tricky. The obvious solution is to provide users an opt-in call home function that reports on breakage during the beta period, though I know there are those who oppose call home functions even when they are opt in and even when they are only for beta periods.

Anyway, just a thought.
I agree with this. The only way this kind of thing will be widely accepted is if it's extremely easy to use, and super straight forward. There should be options to add in whatever ones you want to use as addons, but the ones that come out of the box should be rock solid and idiot proof.
I thought about this issue early on. The fact that we even offer a choice of emus goes against the principles of easy zero-configuration. However, for now it's unavoidable as we don't have any test data. The choice is fairly objective too, so we could rely on feedback on both our and RetroArch's forum instead of data-driven decisions.

Also, most emulators don't offer full platform support - they support only certain extensions/rom formats, and quite a lot don't support loading from within zip files / VFS locations. Adding VFS support to emu cores should be pretty easy in practice (just bypass the file-loading code) though.

In the end, it probably means developers stepping up and helping out the libretro team in emulator maintenance and full API support, something I've been partially neglecting as I focus on getting XBMC's code working.