2013-02-06, 02:18
nope. compile my branch on github
2013-02-06, 02:28
(2013-02-06, 02:18)garbear Wrote: nope. compile my branch on github
Ah, cool! Will compiling your branch on the same box as my working XBMC binary likely break my current config?
2013-02-06, 04:30
Maybe. I swap my profile folder out (C:\Users\Garrett\AppData\Roaming\XBMC) when I switch between frodo and my branch (frodo alpha 5 I think)
2013-02-06, 06:17
2013-02-06, 09:08
Thats great news. Thanks a lot!
I digged a bit into this in the last days and came up with some questions/suggestions. I hope they are no stupid ones.
1. Gamepad support: Is this supposed to be working already? I got it working to recognize the "FullscreenGame"-section in my joystick.xml but now I am struggling that there seems to be no "OnButtonUp"-Event (or no joystick events at all). So if you press a button one time it starts firing but it won't stop until you quit the game. Could this be an error in my setup or is this known not to work atm?
2. Platform detection: Atm there seems to be a lot of file extension based logic. This works well as long as we deal with *.smd, *.smc, etc. -files. It will not work with *.zip-files or at a later stage *.state-files. I think the client (no matter if internal games db or addons) should have the exact knowledge what platform the current game belongs to. So maybe it could pass this info as GameInfoTag to RetroPlayer? This could also be used to let the user choose a specific core as there may be different libretro-cores available for one system.
I digged a bit into this in the last days and came up with some questions/suggestions. I hope they are no stupid ones.
1. Gamepad support: Is this supposed to be working already? I got it working to recognize the "FullscreenGame"-section in my joystick.xml but now I am struggling that there seems to be no "OnButtonUp"-Event (or no joystick events at all). So if you press a button one time it starts firing but it won't stop until you quit the game. Could this be an error in my setup or is this known not to work atm?
2. Platform detection: Atm there seems to be a lot of file extension based logic. This works well as long as we deal with *.smd, *.smc, etc. -files. It will not work with *.zip-files or at a later stage *.state-files. I think the client (no matter if internal games db or addons) should have the exact knowledge what platform the current game belongs to. So maybe it could pass this info as GameInfoTag to RetroPlayer? This could also be used to let the user choose a specific core as there may be different libretro-cores available for one system.
2013-02-06, 12:27
This all sounds super exciting but it is Chinese to me :-)
But I'm very happy there is an update.
Thanks Garbear!
But I'm very happy there is an update.
Thanks Garbear!
2013-02-06, 14:13
(2013-02-06, 09:08)malte Wrote: 1. Gamepad support: Is this supposed to be working already? I got it working to recognize the "FullscreenGame"-section in my joystick.xml but now I am struggling that there seems to be no "OnButtonUp"-Event (or no joystick events at all). So if you press a button one time it starts firing but it won't stop until you quit the game. Could this be an error in my setup or is this known not to work atm?
Gamepad support is very much a loose end right now. Each controller must be individually enumerated by the OS drivers at present, and then a keymap must specifically name the controller. For at least the 360 controller, this means janky functionality in Linux and zero functionality in OSX, where the driver appears to provide no support at all.
2013-02-06, 14:49
I just read this entire thread and I...
Seriously though, this is the most exciting thing I've read in some time. After having tried to get emulators running decently on my system and subsequently given up due to the hassle, the thought of a built-in, minimal hassle setup is drool-worthy.
Seriously though, this is the most exciting thing I've read in some time. After having tried to get emulators running decently on my system and subsequently given up due to the hassle, the thought of a built-in, minimal hassle setup is drool-worthy.
2013-02-06, 16:24
Adam7288, I'll start pre-compiling win32 binaries for eager testers once I rebase on Frodo
malte, input support is kinda a hackjob, I listen for a <keyboard.xml> action and a XBMC_KEYUP event (a key event is translated into a window action). The disparity between actions and events is probably the cause. Polling instead of event-based might fuck up less, so maybe a hybrid of the two is the solution. I've been testing on a keyboard, at some point I'll pull out my Controller S if the buttons havent fallen off yet.
Platform detection is solving the many-to-many problem of platform to extension. I currently ask xbmc for all emulators supporting the extension, and pick the first one (alphabetical? who knows). Emulators report their supported extensions (see retroarch-manual.pdf section 3), but I've seen some lie or return NULL. I use addon.xml to report an emulator's supported platforms, which might kinda sorta help, especially if the emu lies. Is there any good platform selection logic already out there? I plan to solve the ZIP problem by using xbmc's VFS, which can load games (as with movies) directly from inside ZIPs, as well as from FTP/SMB/NFS, but VFS will need emu support. Alternatively, GBC vs SGB vs GB is currently read from binary data in the ROM itself. At the least we'll probably need a map like this. Anyone willing to help with this?
Emulator selection will probably be a function of installed emus, file extension/detected platform, GUI settings and context menu options. For now just disable the undesired emulators
phool..... lol
malte, input support is kinda a hackjob, I listen for a <keyboard.xml> action and a XBMC_KEYUP event (a key event is translated into a window action). The disparity between actions and events is probably the cause. Polling instead of event-based might fuck up less, so maybe a hybrid of the two is the solution. I've been testing on a keyboard, at some point I'll pull out my Controller S if the buttons havent fallen off yet.
Platform detection is solving the many-to-many problem of platform to extension. I currently ask xbmc for all emulators supporting the extension, and pick the first one (alphabetical? who knows). Emulators report their supported extensions (see retroarch-manual.pdf section 3), but I've seen some lie or return NULL. I use addon.xml to report an emulator's supported platforms, which might kinda sorta help, especially if the emu lies. Is there any good platform selection logic already out there? I plan to solve the ZIP problem by using xbmc's VFS, which can load games (as with movies) directly from inside ZIPs, as well as from FTP/SMB/NFS, but VFS will need emu support. Alternatively, GBC vs SGB vs GB is currently read from binary data in the ROM itself. At the least we'll probably need a map like this. Anyone willing to help with this?
Emulator selection will probably be a function of installed emus, file extension/detected platform, GUI settings and context menu options. For now just disable the undesired emulators
phool..... lol
2013-02-06, 17:36
Maybe handle emulator selection the way scraper selection is currently handled? Assign emulators per directory, or maybe even make roms a new source type, where you would select bsnes instead of tv show or movies. I imagine most people have their roms organized by system. Seems like that would provide a consistent experience
2013-02-06, 22:58
Holy F&#$^Balls!!!! I'm with Phool up there +1, +10
Coincidentally, I am smack-dab in the middle of refreshing ROM sets & planning my EMU attack for XBMC, etc. Someone referred me to this thread and ummmm, in the immortal words of natethomas, et. al., "Holy crap!"
Eons ago (1998), I made a cocktail USB MAME/console/pins cabinet. FE was 3darcade. Haven't touched it (or the site) in years, but it is still running strong!!
Check it out for some inspiration guys! http://www.dondi.net/cocktail.htm
Can't wait for this. Thanks for all your hard work everyone!!!
Coincidentally, I am smack-dab in the middle of refreshing ROM sets & planning my EMU attack for XBMC, etc. Someone referred me to this thread and ummmm, in the immortal words of natethomas, et. al., "Holy crap!"
Eons ago (1998), I made a cocktail USB MAME/console/pins cabinet. FE was 3darcade. Haven't touched it (or the site) in years, but it is still running strong!!
Check it out for some inspiration guys! http://www.dondi.net/cocktail.htm
Can't wait for this. Thanks for all your hard work everyone!!!
2013-02-07, 04:46
I agree with Bstrdsmkr's idea, organizing roms into folders by system and then assigning each folder a system such as we do with tv shows/movies/music etc when adding a source might make most sense to keep it consistent across libraries in XBMC.. could take away quite a bit of the logic/guesswork that would need to be developed for something that a dev shouldn't have to stress over, especially for automating the scrapers
Of course this could go against ideas someone developing the full library might have, but I like the consistency feeling
Of course this could go against ideas someone developing the full library might have, but I like the consistency feeling
2013-02-07, 06:49
As a fairly new XBMC user and someone in the planning stage of introducing EMU/retrogaming onto my XBMC fairly soon, I'd like to echo the library/consistency sentiment. And, please excuse me for this post if this is not already a standard, already in the planning or previously discussed or just plain common knowledge.
This media can obviously get quite voluminous, especially with the ROM sets, and as someone with a small 256GB SSD system drive, I already try to keep anything and everything away from my system drive as possible, when dealing with XBMC. It would be great to eventually see ARCADE as a "master" media type and as a Main menu item right alongside the current XBMC menu items; MOVIES, MUSIC, PICTURES, TV, VIDEO, ARCADE.
I have a 12TB RAID hanging off my main XBMC, a 2TB drive on another XBMC client and a NAS with 8TB. Each have a master MEDIA folder that contain the standard MUSIC, PICTURES, MOVIES, VIDEO, etc. folders with accompanying media.
As I plan on implementing my ROMs & EMUs for XBMC, my plan is to create an ARCADE folder under MEDIA. For consistency, and sanity's sake, I think keeping the ROMs, EMUs & Arts for this type of media in separate folders, seems the most logical for maintaining, updating and troubleshooting. I plan on creating 3 folders under the ARCADE folder; ART, ROMs and EMULATORS. These 3 subfolders should contain the exact same number, and named subfolders, according to platform. Then each platform folder can contain their platform-specific sub folders as needed, as the art for 3DO is certainly different from the art for MAME. Then, when you throw-in the XBMC fanarts, cdarts, extrafanarts on top of the standard platform art like, cartridges, marquees, flyers, etc. it can get confusing very quick. This is also ideal for backing up in case of a rebuild or making copies & synchronizing all the stuff scraped by XBMC. It'd be awesome if that were all in one location (ARCADE - location of this folder able to be specified/created on a non-system drive), then, separated by type (ART, ROMs & EMULATOR - although EMULATOR may no longer be needed as that looks like it'll already be included within XBMC) and each of those containing it's relative platform folder.
Again, sorry if this is simply obvious, already thought-out, already a standard, etc. But, as someone relatively new coming-into the XBMC world, I'd just like to relate my growing pains in wrapping my head around maintaining, updating & troubleshooting all of my media for XBMC.
This media can obviously get quite voluminous, especially with the ROM sets, and as someone with a small 256GB SSD system drive, I already try to keep anything and everything away from my system drive as possible, when dealing with XBMC. It would be great to eventually see ARCADE as a "master" media type and as a Main menu item right alongside the current XBMC menu items; MOVIES, MUSIC, PICTURES, TV, VIDEO, ARCADE.
I have a 12TB RAID hanging off my main XBMC, a 2TB drive on another XBMC client and a NAS with 8TB. Each have a master MEDIA folder that contain the standard MUSIC, PICTURES, MOVIES, VIDEO, etc. folders with accompanying media.
As I plan on implementing my ROMs & EMUs for XBMC, my plan is to create an ARCADE folder under MEDIA. For consistency, and sanity's sake, I think keeping the ROMs, EMUs & Arts for this type of media in separate folders, seems the most logical for maintaining, updating and troubleshooting. I plan on creating 3 folders under the ARCADE folder; ART, ROMs and EMULATORS. These 3 subfolders should contain the exact same number, and named subfolders, according to platform. Then each platform folder can contain their platform-specific sub folders as needed, as the art for 3DO is certainly different from the art for MAME. Then, when you throw-in the XBMC fanarts, cdarts, extrafanarts on top of the standard platform art like, cartridges, marquees, flyers, etc. it can get confusing very quick. This is also ideal for backing up in case of a rebuild or making copies & synchronizing all the stuff scraped by XBMC. It'd be awesome if that were all in one location (ARCADE - location of this folder able to be specified/created on a non-system drive), then, separated by type (ART, ROMs & EMULATOR - although EMULATOR may no longer be needed as that looks like it'll already be included within XBMC) and each of those containing it's relative platform folder.
Again, sorry if this is simply obvious, already thought-out, already a standard, etc. But, as someone relatively new coming-into the XBMC world, I'd just like to relate my growing pains in wrapping my head around maintaining, updating & troubleshooting all of my media for XBMC.
2013-02-07, 07:47
I went to my friend's house for a super bowl party and when we were playing some Nintendo emulators I found that it's possible to access a rom stored inside a compressed file such as .zip format. If we can find out how this is done, perhaps we can compress some of the files (roms, etc.) to save space.
