2013-05-01, 00:16
Garbear: We working right now on fixing some issues in libretro cores where we declared zip support in valid_extensions which wasn't true at all. Extension checking should make more sense after these changes.
2013-05-02, 08:21
Cool, thanks for vetting these. I noticed some crashiness once and gave the user a sweeping setting named "Pretend all libretro cores don't support zips (DEBUG only)", but didn't have the time to go hunting down which cores should have zip removed from valid_extensions and which should simply have zlib flags tweaked, etc.
Extension checking wasn't really hampered by the prevalence of cores supporting zip files, if anything it hardened the file opening logic into using multiple other factors backed by some unit tests. Ofc, the more honest cores are, the better a choice can be presented to the user in any given situation.
VFS support might be an area to expand the libretro API into next. For example, (and this already works), if we loaded the zip in the front end (passing the game data as retro_game_info::data and when retro_system_info::need_fullpath is false), this could be an alternative to zip support in the libretro core. RetroPlayer rarely hit the zip crash above because it tried going through the VFS first, and only if need_fullpath was true did it fall back to loading the zip by retro_game_info::path. In this way, RetroArch could add zip and rar support without touching valid_extensions. RetroArch could even add new protocols, like samba or ftp, that libretro cores don't support. I mention this because the virtual file system concept has been pretty successful for XBMC, given that people download files en masse to samba/nfs/ftp servers, zips/rars are popular for downloads, and media is usually on disks so iso9660/udf parsers are nice.
I'll give the VFS part some thought and hunt you down on your forum. Before I forget, here's some ideas from the top of my head...
Extension checking wasn't really hampered by the prevalence of cores supporting zip files, if anything it hardened the file opening logic into using multiple other factors backed by some unit tests. Ofc, the more honest cores are, the better a choice can be presented to the user in any given situation.
VFS support might be an area to expand the libretro API into next. For example, (and this already works), if we loaded the zip in the front end (passing the game data as retro_game_info::data and when retro_system_info::need_fullpath is false), this could be an alternative to zip support in the libretro core. RetroPlayer rarely hit the zip crash above because it tried going through the VFS first, and only if need_fullpath was true did it fall back to loading the zip by retro_game_info::path. In this way, RetroArch could add zip and rar support without touching valid_extensions. RetroArch could even add new protocols, like samba or ftp, that libretro cores don't support. I mention this because the virtual file system concept has been pretty successful for XBMC, given that people download files en masse to samba/nfs/ftp servers, zips/rars are popular for downloads, and media is usually on disks so iso9660/udf parsers are nice.
I'll give the VFS part some thought and hunt you down on your forum. Before I forget, here's some ideas from the top of my head...
- Support accepting a data buffer and a filename, so that the core could reason about its data. E.g. Genesis rom interleaving format based on extension, Genesis Plus GX, loadrom.c#599
- Instead of passing FBA a zip with multiple files, we could pass it a list of (filename, data) tuples
- Alternatively, instead of passing FBA a zip, we could pass it a list of filenames relative to a root VFS directory (game://) and a callback that takes a protocol-relative filename (like game://mvc.11m) and returns the data from the file in the zip.
2013-05-02, 11:05
You should expect it to give you an error message 
I was playing with the code in a debugger -- I could be wrong, but it looked like it took the filename, mvsc.zip, and used the base (mvsc) part to figure out which engine to load. Which is insane -- a different letter in a filename should not affect WHICH program is run entirely. I saw a CRC error also -- did FBA take the CRC of the zip, or its contents? I only question FBA's mechanisms because the documentation seems to be nonexistent, and will probably remain so due to (on a high level at least) the less-than-legal nature of the code, unfortunately.
If you do find a lucky romset and get FBA to work, let us know!
I was playing with the code in a debugger -- I could be wrong, but it looked like it took the filename, mvsc.zip, and used the base (mvsc) part to figure out which engine to load. Which is insane -- a different letter in a filename should not affect WHICH program is run entirely. I saw a CRC error also -- did FBA take the CRC of the zip, or its contents? I only question FBA's mechanisms because the documentation seems to be nonexistent, and will probably remain so due to (on a high level at least) the less-than-legal nature of the code, unfortunately.If you do find a lucky romset and get FBA to work, let us know!
2013-05-02, 18:28
New branch is retroplayer6 at https://github.com/garbear/xbmc . No new changes or fixes (except the ones that were pushed to retroplayer5), the only difference is that retroplayer6 has been rebased on XBMC Gotham alpha 3 and includes the last month's worth of XBMC goodness.
New testers/developers:
To update (assuming you cloned above):
New testers/developers:
Code:
git clone git://github.com/garbear/xbmc.gitTo update (assuming you cloned above):
Code:
git fetch origin
git checkout retroplayer6 -b retroplayer6
2013-05-02, 22:07
There's a line here and I'd remind everyone to stay on the right side of it.
Adding vfs support would open up huge possibilities. Add "xbmc.games" as a new python plugin extension point and suddenly all those homebrew communities could have their content exposed to xbmc the same way video and music have been.
plugin://plugin.games.nesworld/?system=nes&cat=homebrew
shed_single_manly_tear()
Adding vfs support would open up huge possibilities. Add "xbmc.games" as a new python plugin extension point and suddenly all those homebrew communities could have their content exposed to xbmc the same way video and music have been.
plugin://plugin.games.nesworld/?system=nes&cat=homebrew
shed_single_manly_tear()
2013-05-02, 23:59
Small error compiling retroplayer6 under linux:
The fix was to run make distclean under lib/ffmpeg even though I had already tried running it from the root.
http://comments.gmane.org/gmane.comp.vid...user/40666
Code:
make -C ffmpeg
make[2]: Entering directory `/home/ryanroth/retroplayer/lib/ffmpeg'
make[2]: *** No rule to make target `libavcodec/x86/dsputil_mmx_rnd_template.c', needed by `libavcodec/x86/dsputil_mmx.o'. Stop.
make[2]: Leaving directory `/home/ryanroth/retroplayer/lib/ffmpeg'
make[1]: *** [ffmpeg] Error 2
make[1]: Leaving directory `/home/ryanroth/retroplayer/lib'
make: *** [dvdpcodecs] Error 2The fix was to run make distclean under lib/ffmpeg even though I had already tried running it from the root.
http://comments.gmane.org/gmane.comp.vid...user/40666
2013-05-03, 07:48
Drivesoslow, that'll be due to PR2554 - FFmpeg version bump to n1.2.
Bstrdsmkr, I spent some time working with Malte, co-author of Rom Collection Browser, making sure that python and JSON-RPC had as much access to games as they did to music and videos. Currently, RCB extends xbmc.game, but as a script not a plugin. From RCB's addon.xml:
Ofc, on vanilla XBMC, it ignores the <provides>game</provides> and shows up as a Program. I'm writing up a wiki article now about all the additional ways to interface with the RetroPlayer branch via JSON/Python.
...HOWEVER, Bstrdsmkr. You can put away your manly tear, as I have no interest in exposing content "the same way video and music have been." Because when Heimdall is integrated and the game library is functional, i refuse to let the arbitrary divide between local and plugin content carry over. Basically what I'm saying is, you'll be able to scan both into the game library and they'll show up alongside each other
Bstrdsmkr, I spent some time working with Malte, co-author of Rom Collection Browser, making sure that python and JSON-RPC had as much access to games as they did to music and videos. Currently, RCB extends xbmc.game, but as a script not a plugin. From RCB's addon.xml:
Code:
<extension point="xbmc.python.script" library="default.py">
<provides>game</provides>
</extension>Ofc, on vanilla XBMC, it ignores the <provides>game</provides> and shows up as a Program. I'm writing up a wiki article now about all the additional ways to interface with the RetroPlayer branch via JSON/Python.
...HOWEVER, Bstrdsmkr. You can put away your manly tear, as I have no interest in exposing content "the same way video and music have been." Because when Heimdall is integrated and the game library is functional, i refuse to let the arbitrary divide between local and plugin content carry over. Basically what I'm saying is, you'll be able to scan both into the game library and they'll show up alongside each other
2013-05-03, 08:17
2013-05-08, 21:29
I apologize if this has already been addressed, but is there an easy way to change keymappings / find out what the current keymap is?
Using a vanilla xbox 360 wireless controller with the microsoft receiver on a windows box.
Using a vanilla xbox 360 wireless controller with the microsoft receiver on a windows box.
2013-05-08, 21:46
(2013-05-08, 21:29)Adam7288 Wrote: I apologize if this has already been addressed, but is there an easy way to change keymappings / find out what the current keymap is?I believe there is an XML document you can modify/observe.
Using a vanilla xbox 360 wireless controller with the microsoft receiver on a windows box.
2013-05-09, 01:02
Indeed, see #Custom_Joystick_Configuration and this example. The RetroPlayer branch defines some new actions. Also, a change from the main XBMC branch is that analog sticks on gamepads can be used as digital buttons (see my announcement). Hope this info help!
Note: keep an eye on PR2706, as this information may/may not change in the VERY near future.
Note: keep an eye on PR2706, as this information may/may not change in the VERY near future.
