+- 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)
- timdog82001 - 2009-01-22
actually i do like the idea of being able to adjust emulator settings from within XBMC.
- Awen - 2009-01-26
timdog82001 Wrote:actually i do like the idea of being able to adjust emulator settings from within XBMC.
This is an interesting path to follow. Albeit utterly time consuming for a programmer (to handle zillion configuration options and stay up to date within the emulation ecosystem)... I'm now deeply diving into python plug-in paradigm to find some perfect framework for you, guys, to achieve this
- rausch101 - 2009-02-05
Much appreciation for all the work that you're doing, Awen. I know quite a few people who plan to fully adopt XBMC after this piece is added.
- timdog82001 - 2009-02-06
No doubt. I've been perfecting my collections in anticipation..
- AaronG85 - 2009-02-08
any new news on this?
news on this - Awen - 2009-02-08
Not so much, i'm afraid. very little time between various diseases and work. but i'm (more) ok now, and should be able to spend one hour per day on xbmc.
I'm now definitely convinced to let scripts people doing most of the work (not that i'm lazy
), plugin architecture and python integration are now on top of the list... (one or two scripts per emulation platform typically)... I'm going to define all this during next week.
Nice WE 'vrybody
- EMK0 - 2009-02-08
just wounder are these scripts ment to handle emulator settings? or is this for something els?
- Awen - 2009-02-09
Yes absolutely. If 'Scraping' is the natural thing for scripts, 'Emulators settings' could be another in this case: i am personally not aware of every pieces of emulation out there... So, looks like a good way to support all them, plus handling every suggestions you all made in this thread, up to emu auto downloading eventually.
I'm still struggling with some plugin shape questioning: one script per 'platform' (say 'Arcade') handling both Mame app support and arcade roms scraping, or numerous small scripts adressing single needs...
cheers,
- EMK0 - 2009-02-09
yea that's a good idea, so are you going to also make a MAME scrapper that gets the info from MAME its self? or will the program do this since its very different then getting the game name and searching and the Mame roms can be stored in different ways like merged sets, non merged sets, split sets. i believe the command to get info of what roms you have is -verifyroms you can output this to a file. here is a page with all the commands for mame http://mamedev.org/source/docs/config.txt.html with this you can tell it to only show perfect emulated roms, ignore games with steering wheels,light guns and other games that you cant play.
by the way i like your idea to use scripts they could be easily modified and fixed.
found this site its a db for games http://gamesdbase.com/game.aspx?id=535134 check it out you can download manuels for the games and the pictures and things but the bad part is the pictures are watermarked
the manuals are fine tho
Script triggering - Awen - 2009-02-09
Currently, i feel like having 3 entry points for scripts:
1) application/emulators support,
1bis) misce game tools,
2) standard game info scraping.
(2) is the standard way for you script people to work, i only have to, well, comply. (1) and (1bis) will require some work from myself or Terin (or others) to define a dedicated plugin architecture...
(1bis) exists because some applications are rich of possibilities concerning info retrieval fe: you're right to use Mame as an example, as lot of information is available from inner infos when triggering 'mame -listxml'...
So, i suppose that a 'good' mame script would handle inner parameter settings, but some other dedicated info retrieval as well, and maybe various tools like joystick configuration file generator.
(1) and (1bis) may be part of the same script/dialog, or separated menu entries... Eveything is possible at this point.
I'd be happy to read your thoughts about how you'd like scripts to be shaped and called from the core.
- rwparris2 - 2009-02-10
Awen Wrote:Currently, i feel like having 3 entry points for scripts:
1) application/emulators support,
1bis) misce game tools,
2) standard game info scraping.
would you mind explaining how 1) differs from the already existing 'launcher' plugin please?
for 2) are you going to make it so scrapers write directly to a database like how xbmc handles videos and music now, or are you going to want python to handle that part? If python, make sure you set some sort of standard .xml or database structure for us to stick the information in. (btw, are there any good sources to scrape this info from ?)
only 4 some specific frontends - Awen - 2009-02-10
1) scripting is only targeted @ some specific apps frontend. All the db backend and execution code being still in the C++ core: Mame, as an example, has tons of settings and inner infos i'd prefer not to handle by myself. I'd like to give you some scripting opportunities to get all the juice (=params+infos) from such emulation apps. Such scripts would popup a specific dialog concerning a specific app, mainly to generate the perfect cmd line, plus eventually some specific related utilities like parsing the 'mame -listxml' output, or auto downloading the latest version of mame32.
Concerning 2) i already have db tables ready to be filled with infos: many possible sources, and not only web pages but flat files as well (arcade-history.com and history.dat).
I only mentioned 'mame' as an example, it could of course be replaced with 'project64', or 'flash games' or 'local exe/xbe games'...
I know very well that this 'game project' is flirting with some of the 'Launcher' functionnalities, but i'm sure both projects will have diverging paths pretty quickly. Otherwise it would be a failure case.
Does this answer to your questions ?
- djh_ - 2009-02-10
Ready when you are...
Some 1080p ones:
http://www.aeonproject.com/dropbin/aeon_gameinfo_3_1080.jpg
http://www.aeonproject.com/dropbin/aeon_gameinfo_4_1080.jpg
- rausch101 - 2009-02-10
wow djh_ that looks gorgeous
- Nuka1195 - 2009-02-10
how ia this different than if i have my own db using pysqlite? faster?
there are a couple things that would benefit this i believe.
most front ends allow custom game lists. this can be done by sql, but with my limited testing a filter would be faster. so if you could have filterby on any listitem property and the mechanism to cycle thru or select direct with a filterby(property,value) builtin. so if i had a listitem.property(gamelist,1), filter for all gamelist properties that equal 1 should be faster than sql and refilling the list. i think.
currently you can do almost everything other frontends can do just by skinning. but i haven't found a way to quickly switch gamelists. eg mala is real fast switching game lists.
i do agree plugins can handle everything including scraping though.