Author
Topic: Update on the Game Player (Read 1781 times)

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:

Adding 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.

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.

* 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.

Thom,

I couldn't commit the time to helping with the C64 sub-project of this but I would like to help out with this request. I know the amount of work you have put into it. I have a few USB game controllers that LMCE can detect and I would be happy to test games in my limited free time. For something like this I can also hand the remote to guests and ask them to check it out which increases the amount of total test time. I need to chat with you (hopefully in IRC) about a way to get this with my internet situation. I simply can't do a 2GB download + dependencies and libraries from my home. Could you please toss together a list of things I will need to get so that I can DL this at a friends place and save to usb? After I have it all I then need a quick walkthrough of installing from a local source. After reading through L3mce's methods for updating MDs from the core I believe I should be able to do similar with a package like this.

If I don't hear from you after a couple of days I will pull my core from the wall and drive it to that friend's house. Thanks for your work on this and hopefully I can show that by getting you some test and reception data.

JaseP, this needs to be dealt with on another thread in the Developers section.

You typically need a media plugin for each new media type. There is a Game Plugin to handle games, which is paired with the game player device on each media director. I added a small bit of code in Media Plugin's MediaStream class to be able to change the media type on the fly depending on heuristics, so that the Game Plugin could more easily handle a media type for each game system, and thus display its own remote.

Currently, the Game Player code is structured into the following classes:

There are two base classes, EmulatorModel, and EmulatorController. These are classes that hold methods common for all game systems. Many of these methods don't do much on their own, except keep state (for those that need it). The Model keeps things like configuration information, what ROMs are currently running, etc, while the Controller handles the actual work of interacting with the emulation engine. This is a Model-View-Controller (MVC) design pattern that ripples through all of their subclasses.

The base classes handle fabricating a message to send to the App server to launch the emulator, as well as the methods to do things when the emulator stops, or, as I said before, when states change.

Currently, all emulators run under X, and we throw X events at them. In order for this to work, The base classes are subclassed by X11EmulatorModel and X11EmulatorController, which provide all the methods to find the target X11 window, get its Window ID, and sets up a structure to be able to throw X events at it (using WindowUtils).

Then there are the base emulator engine classes which currently subclass X11Emulator*, such as MAMEEmulator* and MESSEmulator* and VICEEmulator*, which provide more refinements for the specific emulations. Right now, these classes refine on X11Emulator* by providing the key mappings and behavior common to all emulations.

Each game system is therefore a subclass of one of the above classes, A2600Emulator derives from MESSEmulator*, C64Emulator* derives from VICEEmulator* etc. If you look at the code for THESE classes, you'll see they are incredibly small. This is the point. These different emulator engines support a wide variety of devices, and all that needs to be changed, are the differences.

The whole structure is designed to be changed, so that when I finally get around to the needed patches to change each of the emulation engines to use a socket level communication interface instead of throwing X11 events at the window, it will work. I imposed an API to try and abstract these differences as much as possible.

The Joypads/Gamepads etc are handled entirely by the target emulation engine while the game display is running.

Honestly, JaseP, you're just going to have to dig in, and look at the code, I can only explain so much, when you haven't even bothered to look at it.

I have been playing around with this for the past couple weeks and you have done a lot of great work! I have found no issues with any of the Sega and NES titles I have and have enjoyed playing them with my kids and showing off the 16bit power of yesteryear. What I have not been able to do though is play any of the SNES titles and I'm not sure if I am doing something wrong or if you would like me to file a ticket. It could be something as simple as the file extension but here is what my log files say...

I have also tried adding them to the snes folder (NTSC) and I get the same issue with over a dozen different titles. The wiki has no information on adding snes ROM titles and I could not discern any file extension problems within the source code I viewed. Any suggestions would be greatly appreciated!

If you can, paste the output of the most recent Spawn_emulator_XXXXX file. One of these gets created each time an emulator gets launched under Game Player. Any errors that may be happening would be happening in here. Also, looking at the App Server log for the media director can be a good indicator of things working/not working.

Thanks, Thom... I figured it would be something like that. As a side note, I saw your youtube video on porting PS1 to the Game Player but do not see any mention of that in this update. Is that something you are still working on or have you put that on hold for now?

I did this with the old Game Player code, as a test. However, I have not written equivalent functionality into the refactored Game Player code, yet, as there are a number of UI issues I want to solve first (controller mapping, memory card management, etc.)