Hello Everyone,
It has been quite a long time since I have really said anything on the Game Plugin. I thought I would give an update, and some of the thoughts I've been having.
The Game Player work started almost 5 years ago (my god, it _has_ been that long!) as a way of diving straight into the deep end of LinuxMCE, and into the part that few dare to traverse, the Media Plugin and its various cousins. It has been a fruitful journey which has produced an integrated way to play games within a LinuxMCE home in the same way as audio and video. There are a few more places to go, but overall, the objectives I've set out to do (even multi room game play for some systems!) have been met, the infrastructure is in place, and what is left, boils down to (MASSIVE!) polishing, adding new game systems, and maintenance of the code going forward.
As it would be while on this journey, I had decided that the first attempt at the Game Player, was just that, a first attempt, and that it needed to be significantly refactored to allow for easier maintenance going forward. I have undertaken the refactoring effort, which took the free time of roughly 9 months, and checked in the results of this work into LinuxMCE 1004 shortly before the beta freeze. This refactoring centered around the need to consolidate as much common functionality across the various emulation engines as possible, while allowing for the tweaks and customizations needed for each emulation engine, and to make it possible for other control mechanisms besides just flinging X keypresses at the emulator's window. While this work can of course be improved, it is already a significant improvement over the original code.
You can see the differences yourself by looking at code in these two trees:
http://svn.linuxmce.org/svn/branches/LinuxMCE-0810/src/Game_Playerhttp://svn.linuxmce.org/svn/branches/LinuxMCE-1004/src/Game_PlayerAdding new systems consists of adding a new model, a new controller (hopefully based on one of the existing classes), and adding the resulting class to the EmulatorFactory. This is enough for the Game Player to be able to handle your new emulation. What is left after this involves making Orbiter controls, and is the subject of my previous Designer screencasts. As soon as I do this work on qOrbiter, I will document that as well, but that is an entirely different subject.
The Game Player can be installed from the Software Modules menu, under Media Directors in the Web Admin. The requisite modules will be installed, as well as a lot of data (there is at this moment, approximately 2 GB of data that comes with the Game Player, so that games can have nice metadata and imagery.) will install itself. After which, you place the requisite ROMs into your media filesystem (we have provided a place under the LinuxMCE file structure, called games, but game roms can be placed anywhere on a media disk that LinuxMCE knows about, UpdateMedia will find them and try to tag them as best it can.) and you can then play the games.
I have provided a way to access the options menus of the target emulator, for now, so that you can do things like set up game controllers and the like. This is not ideal, but it is a start, and will get better as the integration between the emulation engines improve.
Right now, some of the emulations require BIOS ROMs. I can not avoid this. The BIOS ROMs can not be packaged with the system (there ARE some exceptions, but ultimately, a lot of the BIOS rome are still technically under copyright), and these ROMs must be placed currently in the folder of the target system. I will explain this in the documentation which systems require BIOS roms, and which ones do not, and which ones you will need. I can not however, point you to where to get them. Do not ask.
This leaves me with some of the rougher parts of the emulation that I have yet to really deal with:
* Many ROM formats do not have well known identifying characteristics. This makes identification for a target system nothing short of a living hell. So I literally stick with file extensions. You must make sure these file extensions match, or I will not be able to tell what systems these are with. This will change when I finish work on the ROM database.
* There are different variations of given systems, not only NTSC, but PAL variants as well. Currently these are dealt with on a folder basis, a2600 is NTSC, a2600p is PAL. This forces a constraint that a ROM needs to be in a folder labeled this so that I can tell what system to pair with it. This will change with the ROM database, and the System media attribute.
* Many ROM formats are merely dumps of the address space, and have no identifying characteristics of how the address space should be configured. Many cartridges had more ROM than could fit into the address space of their target machines, and thus needed custom bank switching (often called mappers) hardware overcome these limitations. These have to be specified to the target emulation engines, if they aren't, the game can crash, or simply appear to not load.
These points can often produce an undesired effect when loading a random ROM off the street. While some ROM formats (such as the .nes format) provide the necessary information to tell the emulator what to do, many do not. Again, the ROM database will help alleviate these issues.
What is the ROM database?
Some of you who have installed the Game Player in the past, may have noticed the addition of a database, the lmce_game database. This database was traditionally used to hold the information about games in MAME (the Arcade emulation engine we use), so that we can map names like bublbobl.zip to "Bubble Bobble". We have a variety of attributes that are attached to this information, but I have been making subtle changes to this database, to allow the addition of md5 hashes to ROM files. This information will be used to look up a ROM and its relevant metadata, including any system configuration information that may be needed.
In short, it's a step in the direction of making dropping in a ROM "just work"
This ROM database will be used alongside the existing heuristics, to try and figure out ROM names, any additional information, and if available a cover art for the game.
What are these fallback heuristics?
Well, simply, given an example ROM:
Activision Decathlon, The (1984) (Activision).a52
we can gather:
A title: Activision Decathlon, The
A year: 1984
A Manufacturer: Activision.
.a52 tells us it is an Atari 5200 ROM.
And we look for cover art in /home/snap/Activision Decathlon, The.jpg
Which, it does exist, so we use it.
Going forward, instead of using names for the snapshots, the md5 hash will be used for the base of the filename instead, so that we can account for differences in title spelling, in punctuation, or capitalization. If such a file isn't found, the technique just described will be used.
WHAT I NEED FROM INTERESTED PEOPLE:
* Test the Game Player, PLEASE! We need to test this thing, and make sure it works. Please tell me the issues you run into, file tickets, assign them to me, so that I can deal with them, but please take what I have said above into account. The goal is to make all this stuff just work, but it will take time for this to happen.
* If you don't see a box art for a game, please, try to find or make one!
I hope those interested do enjoy the game player. This isn't the end, I still have much more work to do on the game player, again as stated above, and a lot of things need to be polished, but we have a level of integration never before seen on any other platform here, and I want to keep making it better.
-Thom
