+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: RetroPlayer Development (https://forum.kodi.tv/forumdisplay.php?fid=194)
+---- Thread: Games Library (Game & Emulator database + launcher) development project, help wanted! (/showthread.php?tid=40715)
- FaberfoX - 2009-08-05
I've been keeping an eye on this for a while and just recently discovered gamebase (http://www.bu22.com/)
Are this project developers aware of it? So far, I've found gamebases for most platforms, and they include lots of extra info (multiple screenshots, box and manual scans, cabinets / overlays and text instructions)
Gamebase is GPL and uses an access database (.mdb) but the developer is open to moving to something else like SQLite
- flxfxp - 2009-08-07
I created http://wiki.xbmc.org/?title=Talk:Games_Library_Ideas for more concrete discussion on the games library.
- mngrl1 - 2009-08-08
i'm worried think this idea is dead
- sho - 2009-08-08
flxfxp Wrote:I created http://wiki.xbmc.org/?title=Talk:Games_Library_Ideas for more concrete discussion on the games library.Nobody monitors the Wiki Talk pages and the recommendation is to keep these things on the forum.
ApplicationPlayer - bergner - 2009-08-13
Hi,
I have submitted a patch for review in Trac ticket 7046 which does some further work on running applications, interpreters and emulators. The description in Trac is fairly thorough, but the basic idea is to have an ApplicationPlayer class that is responsible for running external applications, since there is already quite a lot of logic in place regarding "players" in xbmc.
Currently it does not directly add the possibility to run files via emulators but given that it becomes possible to associate a "source" in the Programs section with an sprintf-style execution pattern in which a file name can be interpolated the implementation of the actual execution should be straightforward. I made a hard-coded proof of concept with ZSnes and SNES ROMs with about 5 lines of code.
We'll see if the people reviewing the patch decide to shoot the messenger
For those interested the changes are in the gamelibrary branch, although pending review.
Marcus
- SneakerElph - 2009-08-13
Good! I'm really glad to see some progress on this. I can't wait until emulators and PC games are supported as if they were part of the library just like audio and video. This is very exciting.
- junk - 2009-08-13
bergner Wrote:Hi,
I have submitted a patch for review in Trac ticket 7046 which does some further work on running applications, interpreters and emulators. The description in Trac is fairly thorough, but the basic idea is to have an ApplicationPlayer class that is responsible for running external applications, since there is already quite a lot of logic in place regarding "players" in xbmc.
Currently it does not directly add the possibility to run files via emulators but given that it becomes possible to associate a "source" in the Programs section with an sprintf-style execution pattern in which a file name can be interpolated the implementation of the actual execution should be straightforward. I made a hard-coded proof of concept with ZSnes and SNES ROMs with about 5 lines of code.
We'll see if the people reviewing the patch decide to shoot the messenger
For those interested the changes are in the gamelibrary branch, although pending review.
Marcus
I'll add what spiff forgot to write on the trac ticket comment: the initiative is appreciated, glad someone tries to develop this further!
- rausch101 - 2009-08-14
bergner Wrote:Hi,
I have submitted a patch for review in Trac ticket 7046 which does some further work on running applications, interpreters and emulators.
...
For those interested the changes are in the gamelibrary branch, although pending review.
Marcus
That is one hell of a first post. Nice work.
- bergner - 2009-08-14
Well if you want something done you sometimes need to get your own hands a bit dirty. On a more serious note I have done some restructuring based on spiff's feedback in Trac (I basically misunderstood what the heck the old external player was doing), so I have code that runs applications via the old ExternalPlayer instead. It required some minor adjustments, most notably doing a fallback so that if the "external player" used was the empty string and the file used as input was an executable, it uses the executable itself.
I can't say I understand the ins and outs of the external player though (for example there is no place in the code which actually sets an external player and the settings only seem to allow for a single external player). So I'm expecting some chat sessions on #xbmc to help me figure such things out and come up with a decent game plan. :confused2:
Some time later... - bergner - 2009-09-01
Past couple of weeks have been rather busy, but anyway ticket 7046 has now been reworked to use the ExternalPlayer which works well.
My basic idea is to have one scraper per console (I will probably not build any of the actual scrapers) and each such scraper is code wise very similar. They should have settings where you can specify the path to the emulator you want to use and that's about it. A couple of issues remain though, one of which I have another patch pending for:
- Only video scrapers are allowed to have settings. This is due to some hard-coded things in GUIDialogContentSettings. Patch for this is pending review in ticket 7119.
- It does not seem possible to save scraper settings at the moment. I have been testing and stepping using a debugger but there does not seem to be any code that saves scraper settings on disk or in the database. I'm not sure how to tackle that problem at this point.
An alternate approach could be to use separate players for each console, but to me that seems to be much harder to actually get to a point where we can have something that is configurable via the gui and also harder to add support for additional consoles. As a starting point I would like to ignore most of the actual scraping/info gathering process and just have basic scrapers that can handle files with certain file extensions and have some simple associated settings. For example a SNES console scraper would recognize the .smc extension and have a setting where you would need to type in the path to your emulator.
Good ideas are of course welcome.
- spiff - 2009-09-01
see system/playercorefactory.xml and http://wiki.xbmc.org/?title=HOW-TO_use_an_External_Player_for_media_playback
Status update for anyone interested - bergner - 2009-09-20
There is now a gamelibrary2 branch available which is basically a fresh XBMC main branch + patches that has gone into the gamelibrary branch. I have been working a bit with the gamelibrary2 branch and it is possible to run emulators etc. with a bit of manual setup in playercorefactory.xml. As an example, if we want to play files with extension "smc" using ZSnes we setup the following:
Code:
<!-- in the <players> section -->
<player name="SNESPlayer" type="ExternalPlayer">
<filename>path to your ZSnes executable</filename>
</player>
<!-- in the <rules> section -->
<rule name="snes" filetypes="smc" player="SNESPlayer" />Currently on Windows you would need to change the GUIViewStatePrograms.cpp file to not only return files with extensions .exe|.lnk|.cmd|.bat, otherwise you won't even get a listing of your smc files. I have some additional fixes that allows any standalone executable to be run.
There is one serious problem at the moment though. After playing one thing with the external player, the next time you try there is a deadlock in the XBMC graphic context. This needs further investigation and to be honest I'm a bit stuck on that at the moment.
- greatant1337 - 2009-09-21
bergner Wrote:it is possible to run emulators etc. with a bit of manual setup in playercorefactory.xml. As an example, if we want to play files with extension "smc" using ZSnes we setup the following:
Dude, that is sooooooo cool. Keep up the good work.
Also, good thinking on gamelibrary2.
- Loto_Bak - 2009-09-22
I dont know if this has been considered. Forgive me if it has been addressed.
I believe an important feature for this to work properly is consistent input.
XBMC currently uses eventserver as an input method but each emulator/application is going to use its own method to capture input.
This could be a real nightmare configuration wise. What if xbmc were to create its own input interface to the emulators. Then if a input method works in xbmc it will translate easily to the emulator.
- rausch101 - 2009-09-22
Loto_Bak Wrote:I dont know if this has been considered. Forgive me if it has been addressed.
I believe an important feature for this to work properly is consistent input.
XBMC currently uses eventserver as an input method but each emulator/application is going to use its own method to capture input.
This could be a real nightmare configuration wise. What if xbmc were to create its own input interface to the emulators. Then if a input method works in xbmc it will translate easily to the emulator.
I think this would be a great feature, but it would probably be pretty overwhelming for the programmer of this project since it's had a lot of trouble just getting off of its feet. It's only a few more steps for the user to independently create the inputs in each emulator (granted it would be a pain for a large number of emulators) and I think that would be fine until the library itself is actually implemented.
I do think you've mentioned a great idea, Loto, that would definitely complete this project, but I think it's a feature that should wait a bit for implementation. Maybe I'm wrong and there's a method that makes this far more automated than I'm aware, but it seems like a big enough task to warrant a post-alpha implementation.