MAME Plugin Progress Thread

[ddamron]

Thom,

You kill me!  lol

[tschak909]

Well no, think about it

are we supposed to expect everybody to update their entire system libraries and base executables so that it will know about my plugin? that doesn't make any sense.

-Thom

[ddamron]

I understand your reasoning, I wasn't talking about the problem, I was referring to YOU!

lol.. If I could, I'd buy you a beer!

[hari]

Well no, think about it

are we supposed to expect everybody to update their entire system libraries and base executables so that it will know about my plugin? that doesn't make any sense.

-Thom

i think "plugin" refers to "get's plugged into the dce router memory space" and not to "a user can plug that into his system" *grin*
but i am just guessing and don't know for sure..

you could try then we know..

best regards,
Hari

[tschak909]

Okay, a breakthrough!

I recently upgraded my core from 070.4, to 0710 beta 3, and set up a dev environment on it.

I then went through the following steps:

* Defined device templates for MAME Plugin and MAME player, taking their equivalent parameters from the Xine pair.
* built and ran DCEGen on the new templates
* built and ran sql2cpp, to update all constants.
* built the initial stubs to make sure the build is stable, copied them into /usr/pluto/bin
* added the MAME Plugin as a child to the DCE Router
* added the MAME Player as a child to the primary orbiter, making sure the entertainment areas are properly mapped.
* removed unnecessary methods not needed for standalone use.
* implemented the Register, FindDeviceInEntertainmentArea, CreateMediaStream, StartMedia, StopMedia methods patterning after the Xine Plugin
* implemented MAMEMediaStream subclass
* added my new stream type to MediaHandlerInfo.h in Media_Plugin
* added new row to MediaType for the new media type.
* added new row to DeviceTemplate_Mediatype, pointing to the MAME Player
* added new row to MediaType_DesignObj, patterning after Xine player for now
* added new rows to the appropriate fields in Media database.
* added new scenario to trigger local orbiter->Show File List for my new media type.
* force reload router (any time plugin is compiled, router reload must be forced)

As of now, the file list appears, I can select a game, and it will trigger the CreateMediaStream and StartMedia methods in my plugin, updating the Orbiter display as needed. This works great. Now I have to start implementing the various methods in the MAME_Player to launch mame, and swallow the window correctly.

more to come soon.

-Thom

[tschak909]

darn! so close.

I have MAME spawning via the App server...however, there are two things that are happening...

* In full screen mode, I see the MAME screen perfectly, but the orbiter will not come to the front when I ask for it.
* In Windowed mode, the Photo Screen Saver immediately draws over it...

I can definitely attach via WM_CLASS and do some window manager re-ordering bits to make it work..but I am wondering if I am missing something as to how it's supposed to be done... oddly enough, every media player DCE device i've seen just tells the target player to launch "full screen"

any ideas???

-Thom

[Matthew]

darn! so close.

I have MAME spawning via the App server...however, there are two things that are happening...

* In full screen mode, I see the MAME screen perfectly, but the orbiter will not come to the front when I ask for it.
* In Windowed mode, the Photo Screen Saver immediately draws over it...

I can definitely attach via WM_CLASS and do some window manager re-ordering bits to make it work..but I am wondering if I am missing something as to how it's supposed to be done... oddly enough, every media player DCE device i've seen just tells the target player to launch "full screen"

Seems to me that the screensaver starting up means LMCE isn't know that the MAME plugin is started. When the screensaver initializes, can you find in the DCERouter log what's happening right before the screensaver gets the "ON" command? Whatever logic (in the Orbiter, I expect) sends the ON command I suppose isn't seeing the MAME plugin's running state. I don't know if the DCERouter shows traffic indicating that, but it might have a clue. Otherwise, tracing the logic that sends the ON command might have that clue. Or maybe the screensaver logic handling the OFF command shows how to set the state to keep the screensaver off. src/Orbiter/Orbiter.{cpp,h} have lots of references to the ScreenSaver child of the Orbiter. Especially interesting looks like src/Orbiter/Orbiter.cpp: Orbiter::ScreenSaver() starting at line 820.

[ddamron]

Thom,

Great work!

I'm wondering if the screensaver senses another program running? or does the other program need to send a screensaver OFF command first, and then end with and sending it an on?

I'm not that deep into the router, so I could be in left field.

Best of Luck!

Dan

[hari]

did you sent a media playing event?

best regards,
Hari

[tschak909]

from aaron.b:

------

In media_plugin.h notice setnowplaying().  This gets the class name of the window for the active media (comes from one of the mediatype_xxx tables), and forwards it to orbiter as the command
SetNowPlaying. Play media and tail the dcerouter to see this happenng withxine.  When orbitet gets setnowplaying with mediatype!0 it stops photoscreensaver, hides that window, and puts the window described in the classname immediately behind orbiter if orbiter has something to display, or if orbiter has nothing to display other than the full screen media, it puts that window on top with orbiter behind. This is for ui2. For ui1 the media is always on top of orbiter. So if the name of the window class is correctly specified in the db the window management is automatic.

Btw, you know to comment out the loglevels entry in pluto.conf, and reload router (or just reload logs) to get verbose logging. Then you will see in orbiter's log all the window manager commands orbiter is sending, and you can send the same commands with wmctrl

------

I've set the wmclass tuple via the Name property in both the device template, and my device instance... is there somewhere else he is referring to? I don't see a mention of a wm_class anywhere else in the database...

[Matthew]

from aaron.b:

------

In media_plugin.h notice setnowplaying().  This gets the class name of the window for the active media (comes from one of the mediatype_xxx tables), and forwards it to orbiter as the command
SetNowPlaying. Play media and tail the dcerouter to see this happenng withxine.  When orbitet gets setnowplaying with mediatype!0 it stops photoscreensaver, hides that window, and puts the window described in the classname immediately behind orbiter if orbiter has something to display, or if orbiter has nothing to display other than the full screen media, it puts that window on top with orbiter behind. This is for ui2. For ui1 the media is always on top of orbiter. So if the name of the window class is correctly specified in the db the window management is automatic.

Btw, you know to comment out the loglevels entry in pluto.conf, and reload router (or just reload logs) to get verbose logging. Then you will see in orbiter's log all the window manager commands orbiter is sending, and you can send the same commands with wmctrl

------

I've set the wmclass tuple via the Name property in both the device template, and my device instance... is there somewhere else he is referring to? I don't see a mention of a wm_class anywhere else in the database...

So the MD's Orbiter is the hub for local device state? Is there any other component in the system that keeps state?

A better OOP architecture would make the display itself a device which tracks its own state (stored in the DB), and gets events from other devices about what they're doing (in their own terms, like starting up and stopping)., then decides how to react (like starting a countdown to initiating a screensaver). In the current architecture, that could probably be part of the MD's AppServer. Eventually perhaps the display and inputs (kbd, mouse, etc) could be its child devices. The Orbiter itself should have state and logic for only the UI. That would also make replacing it with new UIs, like UI3, a project with a smaller scope.

[tschak909]

The On-Screen orbiter handles window management...which does make sense...

but that doesn't really answer my question.... where the hell do I set WM_CLASS???

-Thom

[tschak909]

HUGE Progress!

As it turns out, I did indeed have to set DATA #156 (Name) to the WM_Class of the window... this was correct...

HOWEVER

I also needed to subclass MediaStream::ContainsVideo, to return true, so that the window management would ACTUALLY HAPPEN, and the Photo_Screen_Saver would STOP.

I still need to do some basic process management, and some bits of code to dynamically write out the correct config files, so that no matter where the roms are, it will "Just Work" .... but... hey, we're very close to having MAME games in LinuxMCE!

And without further ado, THE SCREENIES.

http://www.localeconcept.com/pub/scratch/games/game_playing_with_menu.png
http://www.localeconcept.com/pub/scratch/games/game_playing_with_media.png
http://www.localeconcept.com/pub/scratch/games/game_playing_on_floorplan.png
http://www.localeconcept.com/pub/scratch/games/from_orbiter.png

What do you all think?

-Thom

[dopey]

Wow, that's just F'n awesome and reading about all the work and frustrations you had to endure to get this makes it just that much more impressive!

[tschak909]

the irony is, the WORK involved FIGURING OUT how the system actually _worked_. The code to actually DO the grunt work isn't that difficult.

-Thom