MameHooker wip (2012)

[ids]

Howard, thanks for all the great work.  Long time user of MH and really appreciate it.  Due to recent changes in my cab, tho, I have a feature request: would it be possible to add a TCP/IP socket output option for mame events?  Specifically, when Mame tells MH about something, MH can pass that info along over TCP.

This may sound strange out of context, so here's my explanation....

I have been using MH and its display files to great effect.  Now, however, my secondary screen (a USB driven display) is no longer wired to my mame pc, but rather to a rapsberry pi.  This means I lose out on the display file feature, which I will have to recode for the r-pi.  I am willing to recode this stuff, but will need to be fed the Mame events.  Since MH already does a great job of interpreting Mame events and has so many ways of passing along that info, I thought one more option would not be too bad.  I realize MH could be used as-is to launch another app, or, through other mechanisms, eventually get the data to the r-pi, but I think the most efficient and lag-free approach would be direct communication.  I might be the only person in the world requesting this, so I'd be willing to code it in myself, with your blessing (and perhaps some assistance)

[Howard_Casto]

You really need to post in the 2013 wip post, this is the old one. 

The short of it is I've been working on it.  But honestly I haven't had much luck in finding a reliable solution. 

I want to do something html-based, because html will run on anything.  Also something with as little java and php as possible and NO flash.  Because tablets and lower end hardware doesn't support a lot of that stuff.  Unfortuantely advanced html (with java and scripting and what-not) is not my area of expertise.

I've asked for the community to help in this regard and haven't gotten any. 

What I need somebody else to make is a webpage that loads all potential images in their proper place as elements that can be turned off and on.  Then the page needs to get the data from mamehooker and turn the images on and off.  This could be via reading a text file or a more sophisticated form of communication.  Then it's just a matter of setting up a simple web sever on your cab and you can access the webpage anywhere on your network. 

[MisterB]

I've been tinkering with a web-based approach for displaying MAME data (specifically outputs) for a while.  These posts inspired me to clean it up a bit, and send it out for some feedback.  I basically wired the MAMEInterop logic into a web server, which can serve up output states as JSON via a standard HTTP request, and also provides a WebSocket interface to receive output events in realtime, eliminating the need for a polling loop.  I think it's a solid enough foundation that anyone w/ some web-programming savvy can generate some slick interfaces on top of it.  While I haven't had much time to dress it up, this package includes some examples of how to access the MAME data, as well as tablet-friendly animated artwork for Spy Hunter, which might inspire some folks.  Very similar to what Howard was describing - no java, php, or Flash.  This can all be done in straight HTML5, since the MAME integration is build right into the server.

It should also be usable in a browser on the Pi - just need to translate more display files to get it on par w/ MAMEHooker.

I haven't tested this on multiple machines, so I'm not sure if it will distribute cleanly.  But I'd love some feedback.  Just unzip and run MAMEWeb.exe.  It defaults to port 80, but you can change if needed (MAMEWeb.exe --help for more info).  If you guys think this is useful, I may post it to its own thread.

https://www.dropbox.com/s/blueb3z7f3zd2li/MAMEWeb.zip

[ids]

want

was going to develop something similar myself, but looks like it's already done!

Dropbox blocked in the office i'll have a look asap

[ids]

MrB - did some testing with your app.  Good stuff.  I did have some occasional and seemingly random crashes when mame was launched via Hyperspin.  I was also wondering if it would make sense to add the rom name to the mame start message(s), rather than require a query to "/status"?

Great stuff.  Thanks!

[Howard_Casto]

Not sure why everybody keeps posting in the 2012 wip when I started a 2013, but whatever....

The webpage bit is that part that always boggled me.  I can send stuff from a webpage to a app, but the other way around... eh I never got it. 

If you'll tell me the protocol you are using along with the variables needed ect I can probably add an option to mamehooker to send the data.  Somebody else just needs to do the html bit. 

In terms of the multi-rom bit.  I could send the current rom constantly along with the output states.  If it ever changes the page could do a simple re-direct. 


Just let me know. 

[MisterB]

IDs, I believe I am sending the full "status" JSON along with the mame_start event in the WebSocket implementation.  Are you seeing that when using the overview/demo page?  I can certainly include it every output event as well - is there a preference?  Regarding the crashing, did you receive any error messages?  Can you send along some more details on your system specs?  Personally, I've been running this as standlone for testing, I haven't run it alongside Hyperspin yet.  It could be related to frequent game loads - I'll get it set up and see if I can recreate the issue as well.

Howard, the protocol you are looking for is WebSockets.  I know you are typically a VB guy - I tried doing some quick searches for a simple VB server implemetation with limited success.  But http://stackoverflow.com/questions/12931276/websocket-server-vb-net-data-frame has some decent code snippets, and a reference to the official specification.  Maybe that would be helpful as a starting point?

[Howard_Casto]

Well that's not good.  Websockets is fairly new and not everything supports it.  Unless you download a custom web browser android doesn't support it at all.  IE just started supporting it with version 10, which isn't available on xp or vista.  The main one I'm worried about though is the mobile devices it's pretty sketchy on those. 

We'll give it a shot, but I dunno. 

[Howard_Casto]

Oh I forgot to mention that I can send anything over the net via winsock or a similar api, so that part won't be an issue.  I've just got to figure out the protocol.  sha1 hashes!  bah!

[MisterB]

I assume you found something similar to this: http://caniuse.com/websockets.  I'm a little surprised that the Android browser doesn't support this yet (I'm on iOS for mobile), but as you mentioned, there are 3rd party alternatives.  Google's usually pretty good about support for these types of things, so I've got to believe that it will be coming soon (already great support in Chrome).  Anyway, this is the standards-compliant way to support always open, bi-directional communications in a browser going forward, so it's worth the investment.  If you are looking for backwards compatibility, you could also set up a simple HTTP server that just serves up a JSON-formatted string with the MAME information (see the /status page in my demo).  The downside is the browser has to poll for it, so it won't be realtime, but any browser will be compatible.

[Howard_Casto]

Yeah it kind of shocked me to be honest.  I expect ie to be a little behind because it always is, but not android. 

I'll work on this when I get time.... just spent the better part of an afternoon pulling the heatcore bypass assembly out of a 99 ford Taurus.  Look that up some time and have a laugh and one of the stupidest hose designs you've ever seen. 

On the html end of things:

I haven't really looked at your code in-depth, but I noticed that you hard-coded the image names in the layout file.  This is something where we might run into issues.  For spyhunter it's ok, there is only one image, but each "image" in a display file is actually a array of images and the "#" portion of the filename represents the state number of the output.  7-segment displays, for example, have dozens to hundreds of images per image entry.  Spyhunter's "0" image doesn't exist because it doesn't need to.  mamehooker loads a empty image container whenever the file doesn't exist.  I can see how this would cause issues on a html layout.  What we could do is add a 16x16 blank png file that's completely transparent.  Do a file check when the page starts up and load the blank png whenever a file isn't found.  It's sloppy that way, but at least you don't have to do special code.  Like I said, I haven't had a chance to look really closely, you might already be doing that, but I thought I would mention it.  If it's a parsing issue, we could split the "image" variable in the layout to "imagestart" and "imageend" and you'd load the image by combining the two with the state value in the middle.

[MisterB]

I haven't put much effort into a standard, reusable approach doing the layouts yet.  Most of the work has gone into server side of things, and building a Python version of the Interop to bundle in the server (which is built on Tornado - trying to be lightweight - wasn't interested in doing this in Apache or IIS).  On the client side, I spent far too much time just getting the artwork layouts to dynamically resize and reposition on an orientation change.  I used Spy Hunter to prove this out as a general concept, and got it all working.  Now it's time to look at a more reusable approach - thanks for raising the bar

Do you have some recommended games I can look at for more complex layouts?  Perhaps something w/ a 7-segment display?

[Howard_Casto]

Yeah Sega Turbo is probably your best bet, it's got multiple 7-segments and a few blinky lights. 

It also will help you understand the concept of how I use the arrays a little better.  All mame 7-segment outputs use the game's native bit-wise numbers, so they don't output a "9", to display 9, they'll output 109 or something similar.  In a standard 7-segment display you have 128 possible images for the different combinations of the segments.  Normally I'd just add 7-segment support, but different games use different bit values.  To make things process quickly I actually have an array of 128 images for each digit-pre loaded.  But to keep things snappy I actually only have images in about 12 slots as that's all turbo uses.  For the other 118-ish slots per digit I have an empty image container. 

You'll notice in my format a "length" value... that doesn't refer to the dimensions of the image but rather the size of the array.  So for each image, I make an array the size of the length defined.  Then I go all the way down the line checking if images exist for each potential value (in this case digit_0.png to digit_128.png).  Each image is loaded for speeds sake and they all share the same dimensions defined, only I turn the visibility off for each one.  Then when a value for that image array is sent in, I turn the previous value invisible and turn the proper one in the array visible.  Of course you could also just turn them all invisible and turn the new one on... it'll work either way.   

[ids]

MrB, here's what I see on the console, with the "-v" flag (no game name):

DEBUG:mameweb:MAME: Started
DEBUG:mameweb:WEBSOCKET: Message sent : {"Event": "mame_start"}
DEBUG:mameweb:MAME: Output (Orientation(\\.\DISPLAY1), 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (pause, 1)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"pause": "1"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (pause, 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"pause": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Stopped
DEBUG:mameweb:WEBSOCKET: Message sent : {"Event": "mame_stop"}
DEBUG:mameweb:MAME: Started
DEBUG:mameweb:WEBSOCKET: Message sent : {"Event": "mame_start"}
DEBUG:mameweb:MAME: Output (Orientation(\\.\DISPLAY1), 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (knocker0, 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"knocker0": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (knocker0, 1)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"knocker0": "1"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (knocker0, 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"knocker0": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (knocker0, 1)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"knocker0": "1"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Output (knocker0, 0)
DEBUG:mameweb:WEBSOCKET: Message sent : {"Data": {"knocker0": "0"}, "Event": "mame_output"}
DEBUG:mameweb:MAME: Stopped
DEBUG:mameweb:WEBSOCKET: Message sent : {"Event": "mame_stop"}



And the matching log from the client side (again, no game name, let me know if you want the code for the client side demo app):

--received message: {"Event": "mame_start"}
--received message: {"Data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "Event": "mame_output"}
--received message: {"Data": {"pause": "1"}, "Event": "mame_output"}
--received message: {"Data": {"pause": "0"}, "Event": "mame_output"}
--received message: {"Event": "mame_stop"}
--received message: {"Event": "mame_start"}
--received message: {"Data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "Event": "mame_output"}
--received message: {"Data": {"knocker0": "0"}, "Event": "mame_output"}
--received message: {"Data": {"knocker0": "1"}, "Event": "mame_output"}
--received message: {"Data": {"knocker0": "0"}, "Event": "mame_output"}
--received message: {"Data": {"knocker0": "1"}, "Event": "mame_output"}
--received message: {"Data": {"knocker0": "0"}, "Event": "mame_output"}
--received message: {"Event": "mame_stop"}

[MisterB]

ids -

I will add the ROM name to the MAMEStart and Output events, so it is always accessible without a call to /status.  Just adding it to MAMEStart is not a perfect solution - it fires when MAME is started  , but MAME can be started without a ROM, in which case it presents you with a selection menu.  Unfortunately, when a ROM is selected through the menu, it does not trigger an output event to tell you what the selection was.

I can add some code that detects when the ROM name actually changes, and create a custom output event...should be easy enough.  Give me a couple of days - I should have something for you by the weekend.

Howard -

I've also made some good progress on creating a reusable solution for HTML artwork layouts.  I've completely rewritten and simplified the layout logic, and have implemented most of the output processing.  I completely understand the approach with image arrays and am doing the same thing.  In fact, to keep this as simple as possible, I am directly loading and parsing your .ini and .dis files in the browser, so I don't have to create custom layouts - I can rely entirely on the great work you've already done.

One question for you....in MAMEHooker, when you are converting the relative dimensions and positions in the .dis file to absolute values, how are you rounding the results?  When I calculate it all out, I end up with fractional X/Y values all over the place...when I start compounding a fractional positions for the background image with fractional positions of the overlays, the overlays are slightly out of position (very noticeable in the tachometer in turbo, as "SPEED" is part of both the background and overlay).  I'm guessing you dealt with a similar issue in MAMEHooker, and if I adopt the same logic as you, I can continue to use your .dis files without modification.

[MisterB]

ids - one other thing....are you still getting the MAMEWeb crashes when using Hyperspin?  Are you getting any stack traces from the crash that you could send along?

[ids]

ids - one other thing....are you still getting the MAMEWeb crashes when using Hyperspin?  Are you getting any stack traces from the crash that you could send along?

It did not crash with the most recent testing.  In the past, there was no stack trace or anything else, the window/console was just gone.  I'll do some more exhaustive testing as soon as I get a chance.   Is there any log file output?

[MisterB]

Not yet, but I will add it in as part of the next update.

[MisterB]

ids - MAMEWeb has been updated - same location as before: https://www.dropbox.com/s/blueb3z7f3zd2li/MAMEWeb.zip

This is just an update of the MAMEWeb executable - the www contents are the same.  I have not yet included the MAMEHooker Artwork updates, as they are still in progress.  Take it for a spin, and let me know how it works for you.

Howard, any thoughts on my relative positioning question from a few days back?

Brief Changelog:

• JSON formatting tweaks.  Use the websocket viewer on the demo page to see the changes.
• ROM change generates a custom event
• Sending a "status" message over the websocket returns all data, similar to http://localhost/status
• Log messages are sent to the console and MAMEWeb.log

Once I get some feedback on this release and complete the Artwork code, I'll stop hijacking this thread and start a new one.  There seems to be some momentum behind web-based front-end & emulation controls right now.  It's probably best to tbring a little more attention to this project.

[Howard_Casto]

I haven't messed with the display stuff in ages, so I had to look back at my code. 

To be honest, I don't round the values.... not at all.  I'm using image containers on my display window and like most visual studio languages, if you feed a image a x value of 235.6535 It moves it 235.6535, there isn't any kind of construct that requires size or positional data to fall on an even number. There might be some internal rounding, but it isn't by much.  Also what's the best degree of precision with html formatting?  I'm using twips, which is roughly 1/16th of a pixel. 

[Howard_Casto]

*Update*

I did some testing to see what vb is doing with the values I send.  It's rounding to the nearest twip.....  I'm not sure if that's even helpful because I'm not sure if html supports twips, but like I said, one twip is roughly 1/16th of a pixel so that's still pretty precise.  Rounding to the nearest pixel would probably get you into the ballpark. 

[Howard_Casto]

Oh I should also mention that the turbo display file was done before I implemented transparency support.  If it would help I could easily make the backgrounds on those sprites transparent and we could black out the rpm/speedo area of the background image.  So we've got options. 

Also note that the display files aren't perfect... I took the images from Mr Do's artwork files and with permission converted them manually.  At the time the goal was to get a bunch out the door so people would start using the feature, so a few of them could use a good cleanup.  I don't have the issues you are referring to in turbo though.  I love display files, but they never caught on the way I hoped they would.  Especially now that mame has proper dual screen artwork support.  They have a very limited use at this point.   

[Howard_Casto]

Ok I'm finally getting around to setting this up so I can implement the protocol for mamehooker.  Thus far I haven't had much luck with your app. 

In IE the thing just refuses to load.... I get a blank page (it's the latest version of IE btw)  In Chrome the page loads but the lights don't update.  I'm not sure if I have the proper browser in android installed, I'll check on it, but thus far it isn't working either. 

Are there any special server-side things I need to do?  I'm just using the default port 80.... windows hasn't complained nor has my router. 

[MisterB]

I haven't played with this at all on IE...I can try to debug that tonight.  What versions of Windows and IE are you using?

Regarding Chrome, I just realized that the MAMEWeb updates I published last night broke some of the client side code in the original demo.  Thanks for catching that.  It's a easy fix that I can address tonight. But the entire Artwork code will be completely overhauled in the next week and make that demo irrelevant.

Thanks for the update on the twips...not sure if it matters or not in this case, but I will research it.  I am wondering if the issue is exaggerated because I am using high pixel destiny Retina displays on my IPad and laptop...

[Howard_Casto]

Well IE10 is the only version that supports websockets, so I'm using that. 

In chrome, on the demo page, if I click the button at the bottom it does show the proper messages, I just don't get the updates to the display file. 


We might want to have mamehooker send messages to your app rather than me adding stand-alone support.  I didn't realize that your app has a built in webserver, which makes things easier to the user.  The reason I say this is mh doesn't use any kind of multi-threading (yet) so if I put a web server in the code, it would probably slow things down dramatically.  I've got various methods for sending data.... DDE is my fav but I'm flexible.  If you are just wanting to control mame-related stuff your app is going to work just fine as-is... but if you want to send other stuff, like move lists, ect mh might be required.  Also mh will support model 2 via the troubleshooter, so there's that. 

[ids]

Looking great from my testing - all the info appears to be there.  Logs from my sample app:

--received message: {"data": {"mame_running": false, "outputs": {}, "pause": "0", "rom": ""}, "event": "websocket_open"}
--received message: {"data": {}, "event": "mame_start"}
--received message: {"data": {"rom": "joust"}, "event": "mame_rom"}
--received message: {"data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "event": "mame_output"}
--received message: {"data": {}, "event": "mame_stop"}
--received message: {"data": {}, "event": "mame_start"}
--received message: {"data": {"rom": "qbert"}, "event": "mame_rom"}
--received message: {"data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "event": "mame_output"}
--received message: {"data": {"knocker0": "0"}, "event": "mame_output"}
--received message: {"data": {"knocker0": "1"}, "event": "mame_output"}
--received message: {"data": {"knocker0": "0"}, "event": "mame_output"}
--received message: {"data": {}, "event": "mame_stop"}
--received message: {"data": {}, "event": "mame_start"}
--received message: {"data": {"rom": "qbert"}, "event": "mame_rom"}
--received message: {"data": {"Orientation(\\\\.\\DISPLAY1)": "0"}, "event": "mame_output"}
--received message: {"data": {}, "event": "mame_stop"}

I'll do more thorough testing asap to see if I can recreate the crashing I experienced a while back

[MisterB]

OK, another update has been posted to the same location.  The SpyHunter demo has been updated to work with the latest MAMEWeb.  I validated it in Chrome.  IE10 websocket functionality works fine - you can verify it on the default page.  But it doesn't work with the SpyHunter demo...I'm not going to spend any time trying to figure out why, since I'm rewriting the artwork logic.

Howard, I'm open to providing a web-based extension to MAMEHooker through my app.  My only concern is that I'm not a Windows developer...just getting the MAMEInterop logic built in took a fair amount of trial & error.  The easiest way for me to integrate would probably be through the method as MAME - I guess that is Windows Messages - since I already have that working.  Is that possible, or should I be doing some research into DDE?

[Howard_Casto]

Well it's possible, but wouldn't we run into issues?  I mean if I set it up mame style, when a game starts in mame you are going to get messages form mame and then I'd be sending the same messages via mamehooker. 

Also there is a weird thing with VB that might cause issue.  I can send/receive windows messages just fine, but due to the way C handles strings, they aren't directly compatible with vb.  Headkaze actually made me a C dll ages ago because we tried everything we could think of and never did get the string part working properly in vb. 

So I could certainly send windows messages, but we'd have to do it a different way than mame does it.  Perhaps instead of sending a pointer to the string, I could just send the actual string, via an array of bytes? We'd have to limit the character length to something sensible (like 255 bytes) but that shouldn't cause any issues for our use.

Of course since we are dealing exclusively with display files with your app, we really don't have to conform to mame-style messages.  We can use mh-style commands such as "load display file" and "set display state"

[MisterB]

I didn't mean that you would need to actually look like a MAME instance, just that I could grab a handle to MAMEHooker and exchange messages in the same manner.  Regardless, I did some research into DDE last night, and found some Python-based implementations.  I doesn't look like it would be difficult to implement a DDE client if that is your preferred method, and I'm open to learning it.  Does MAMEHooker have DDE server capabilities today that I can experiment with?

I'll leave it up to you on which commands and data you would want to expose - just send along the details, and I'll think through the websocket implementation, and if any changes to the current JSON data representation is required.  For the most part, I will just be a proxy.  It's the web frontend and Javascript API that will make this useful and interesting.  But let's get the plumbing in place first...

Regarding potential overlaps/conflicts between my current direct-to-MAME implementation and MAMEHooker, I plan to implement both and allow the user to select which one they want.  Like you said, the MAME stuff works fine as-is.  So if someone doesn't want to learn or use MAMEHooker, they can still use MAMEWeb.

[Howard_Casto]

ATM mh only receives DDE messages.  It can send them as well, but only to itself (that's how the command line interface works, mh checks for a previous instance of itself and if it finds it, sends the command line commands on to the first instance and closes itself). 

 But since the code is in there anyway, it would literally take me 5 min to add the ability to send messages. 

The main reason I like DDE is because I can use it strictly in a one-way sense, which simplifies things for both client and server.  Of course we can do that with windows messages as well. 

In terms of what mh does with display files it only has two functions:

"lds romname" which loads the display file.... would be the equivalent of mamestart for your purposes
"sds elementnumber value" which sets the element number specified to the image array number specified. 

Mamehooker also automatically unloads the display file when the game ends, which in your case would probably involve re-directing the html body to a generic homepage.

There are a few specialty flags you should be aware of though which it may or may not be possible to implement. 

Display files support the following flags:

%mamepath% = Path to mame as stored in the mamehooker.ini
%rpd% = Rom/Parent/Driver.... Mh searches first for the string with the rom, then the parent and then the driver to get the best results.
%rom%
%parent%
%driver%

In addition absolute paths are supported as is the option for an image element to keep it's aspect ratio.  All of these special flags were added so that a game's artwork could easily be displayed with a singular display file. 

That might be a heavy order to do all of that file searching via scripting.  If it would be helpful, mh could write a pre-parsed display file to use prior to sending the start message.

In addition the sds command supports offsets as well as absolute values.  So a value of +2 would make the current element value increase by two and a value of -5 would decrease it by 5 ect.  That isn't particularly useful for your end of things.  I mainly added that for displaying movelists and ect so the user could control what's displayed via keypresses. 

It's up to you really. 

If you are interested in the DDE route I can send you a little test app with all the appropriate commands built in, or we can play around with windows messages and I can make a test app for that.  The details can be worked out as we go. 

[Howard_Casto]

In case you want to go the dde route, here is a little DDE app. 

DDE (in terms of sending things at least) couldn't be simpler.  Set your server name, set your topic name, and your string message. 

The server end of things is *slightly* more complex, but it still isn't too bad.

Mamehooker currently repeats any message sent to it in the debug window. 

If you setup a dde server in your app, all you need to do is give me the server/topic name you've chosen and the strings it expects. 

I have other DDE examples if you need them, but in terms of making sure your server can receive messages from mamehooker, this is all you really need as this is the implementation I use. 

[MisterB]

Thanks!  I will play around with this and try to get a DDE server up & running.

[MisterB]

So, I have the DDE server up & running, and it is receiving messages through the test app that you provided.  Thank you.  But now I am trying to add DDE Client functionality as well, so I can also send commands back to MAMEHooker.  However, I can't get your test app or my code to communicate with it.

I am using the following:
Server: MHServer
Topic: MH

My program states that it cannot connect.  Your test program doesn't show an error, but nothing appears to register with MAMEHooker.  FWIW, passing MH commands over the command line works fine.  Any thoughts?

[Howard_Casto]

The topic is "MHDDE", not "MH"  that should do it. 

But keep in mind that as of the latest public build, dde commands are pseudo broken.  MH will repeat them, and direct, command-line style strings will work, but some of the others won't.

The new MH build will literally be out within the next month or so though, so I wouldn't sweat the details that much. 

[MisterB]

For anyone who was tracking this (ids, maybe its just you) - just wanted to let you know that the MAMEWeb project hasn't died.  The real world stole most of April, but I've been back on this in the past week.  The DDE integration is operational, and the web-based MAMEHooker display is completely functional.  But I have been re-writing the browser-side display code from scratch to improve page loading and rendering times.  On older devices, it was taking several seconds to load a display.  But I have some caching code that seem to be helping.  Once it is ready, I'll finally abandon Howard's thread Stay tuned.

[ids]

Thanks for the update.  In lieu of nagging I had actually begun playing with the code available on Howards site.  My needs are perhaps a bit different - I just want mame events sent over the wire.  This is to feed a raspberry pi embedded in my control panel, which drives a USB display.  By telling the r-pi which game started, stopped, etc, it can display the appropriate things.  I've had mixed results to date, and would welcome a replacement.  (I've also customized some code I found on the net which sends Windowz shutdown events over the wire, so the r-pi can shutdown cleanly at the same time.)

[Howard_Casto]

For anyone who was tracking this (ids, maybe its just you) - just wanted to let you know that the MAMEWeb project hasn't died.  The real world stole most of April, but I've been back on this in the past week.  The DDE integration is operational, and the web-based MAMEHooker display is completely functional.  But I have been re-writing the browser-side display code from scratch to improve page loading and rendering times.  On older devices, it was taking several seconds to load a display.  But I have some caching code that seem to be helping.  Once it is ready, I'll finally abandon Howard's thread Stay tuned.

Man I wouldn't worry about it.  I used to give myself time constraints and then realized it just wasn't worth it.  I think it's been around two years since the last MH release. 

TS2 should have been out and done by now, but it seems like every car and household appliance in the family has decided to break on me this month.  So I've been busy.  I figured I would do the MH release last anyway, in case you wanted me to add anything to the code.  So take your time and if you need anything on my end let me know. 

ids:  You know I didn't mention this because I'm still not quite sure what you are doing, but there is such a thing as netdde, that will work over a lan.  I'm not sure if the pi would have support, but that might be an easier option.... you could download the (now ancient) netdde server from Microsoft, set it up for mamehooker and then run a client side app on your pi. 

[ids]

Howard, sorry to hear about the appliance problems.

I will definitely look into netdde, thanks for the heads-up on that.  As long as non-Windows platforms are supported, it might just be what I am looking for.

What I am doing is basically a second screen to display marquees, instruction cards, and/or what ever might be available.  I think this is not particularly unusual in itself.  The difference is that my display is a USB driven one, embedded in the control panel, and it's driven by an embedded raspberry-pi running Linux.  The r-pi and mame cab are networked, so that is the primary means through which they can communicate.  I've also written my own app for this display so that it can be more dynamic than other apps I've seen to date.  Dynamic in that it will deal with whatever artwork is available, and gracefully handle any artwork that is not available.  For example, not all games have instruction cards.  I don't want a blank spot on screen where one should have been, but I do want it shown if available.  Also, some things, such as the instructions for some fighting games, are very wide, and downsizing them to fit would make them unreadable.  In such a case my app will choose an appropriate scale, and slowly pan back and forth.  Some games may have only a marquee, which leaves a lot of blank space, so I scroll the history.dat info in the remaining space.  I also look at aspect ratio's and auto-fit things, within certain constraints, to make best use of space.  That's the software.  The use of the raspberry-pi hardware helps ensure that this software does not bog down the mame cab itself.  Experience has shown that the USB display can be a bit taxing on the system, since it cannot use your vid card.  To make it all work, the r-pi app needs to know when a game starts and stops so it can display the right game related artwork at the appropriate times.  I am also working on a mashup animation of various game characters and backdrops to fill in time between games.  I may also attempt to recreate the MH display file thing so I can support those extra features without requiring a browser or windows.


Sorry for the threadjacking.

[yangfeng]

If you can give a scenario so I can get a better idea I might be able to point you in the right direction.





___________________________________________________________________
"Do you know those times when you've been put through so much pain you couldn't bear it? Well, that's reality for you."

I have been a FunForFreedom survivor since 7/2/12!
Diablo 3 Gold
Buy Runescape Gold
Buy RS Gold
Supporting Leon X Zara! <3
I have a blog!