MameHooker wip (2012)

[Howard_Casto]

Ok now that I've gotten some of these oddball programs out of my system, it's time to button up mamehooker for the next release!

I took a look at the source code from where I left off.  Boy I should have finished the FF stuff while it was fresh in my mind!  Anyway, from the looks of it, I managed to finish the tweak file functions for custom effects just before I quit.  What's left is to hook them up to functions that you guys can call and testing.... a butt load of testing.  I'm going to leave that up you the users actually.  I only have a couple of ff devices and I'll do my best to test with them, but I'm not going to be able to test everything.

I'm not feeling up to working on this seriously atm, but I've opened up the code and I'm playing with it, so at least there is progress.  I'm hoping we can get a really good release out before summer hits us. 

On another front I'm really dead set on being able to use the artwork files on remote devices via the web.  I sure could use some help on that front because other than some really simple javascript, I'm kind of dumb in regards to coding advanced html. 

Maybe if I explain what I want to do some of you webpage experts can help. 

First off there will be a html page that is essentially empty.  All this html page does is constantly check the time stamp of two csv files, layout.csv and states.csv. 

When a new layout.csv is found, the layout of a artwork file is loaded from within the file, a layout is nothing more than a bunch of images and the csv file would contain the url, the dimensions and placement of the image in percentage of the screen and the z-order.  The dimensions and position values would have to be multipled by the webbrowsers' window dimensons to scale the layout as they are loaded in.  Because of the amount of images (potentially dozens) a layout would take a while to load, but fortunately it would only have to be loaded at the start of a game. 

States.csv would constantly be reloading after this, potentially at 60fps (although most games rarely change outputs that quickly).  States.csv would just contain the visability value of all the images you loaded into the array when you loaded layout.csv  We would simply toggle the visibility of the images on and off.


Now I sorta kind of know how to do this in regards to loading the files, but my issues and questions revolve around the loop that would be required to constantly check these files, the cross compatability (I at least want this to work on a pc browser and an android one.) And the amount of resources required.

What kind of loop should be used?  I tried a simple javascript refresh before, but sometimes the file would be locked (mamehooker was writing to it) and the page would just crap all over itself, displaying a white screen.  What about system resources?  If the images are all loaded could something as puny as a tablet render images taht are rapidly turning on and off fast enough?

[nipsmg]

Howard,

I can help you with implementation, but I'm having a hard time wrapping my head around WHY you would do this?  If you can give a scenario so I can get a better idea I might be able to point you in the right direction.

[Howard_Casto]

Ease of use and nothing more.

The idea of using a smaller, secondary monitor to display useful information on a mame cab has been thrown around a lot, but because it isn't very practical (you have to deal with dual video cards and the annoyances that come with them and having to physically build a space for the monitor)and  it hasn't really caught on. 

The tablet/smartphone/e-reader revolution should change all that.  Aside from using mamehooker to display output-based layout files it can display movesets, instruction cards, ect.  Imagine walking up to a mame cab, turning on your tablet and navigating to a specified url... all of  the useful data on the game you are playing shows up on your tablet.  You can allow mamehooker to control what is being viewed or navigate independantly... something you can't really do on a dual monitor setup without running into issues.  When a new game is selected, the page re-navigates itself.... there isnt' any need for the user to look it up. 

And of course with such a setup there aren't any hardware/software concerns.... if your device can view a webpage then it will work!  It's as simple as that.  Friends can come over, pull out their phones, and they've got a movelist available to them.  It just eliminates a lot of the hassle of making things user-friendly. 

[Howard_Casto]

I'm messing with a few more things that I want to have in the next release.

Apparently nobody is using this, but MAMEhooker can be controlled by other devices via  DDE (winsock) interface.  The idea behind this was that people writing apps that want to add output support for anything coudl simply talk to mamehooker instead of having to hardcode support for 2 dozen or so devices.  In other words, as it pertains to our hobby, windows apps should no longer be controlling ledwiz/pacdrive/ect directly, they should go through mamehooker.

This never caught on... I think it's because DDE is a bit hard to code for, so developers would rather just add support for devices themselves.

I'm going to add two new methods to control mamehooker remotely. 

The first one is window title parsing.  You know that tutorial on my site to display a marquee on a secondary monitor?  This is mostly for that.  90% of your third party emulators have a title bar similar to the following.

Emulator Name: Rom or Game Name

Via an optional setup, mamehooker will periodically check the active window when mame isn't running and if it's one of the configured emulators, it will extract the rom name (either directly or by comparing the game name in the title to a list) and simulate a mamestart event and set the rom to the one found in the title.  This allows marquees to change even if you are running model 2 or supermodel.... just as long as the title gives us some sort of unique game identifier. 

Of course if the application is coded specifically for mamehooker, this functionality can be expanded upon.  A developer can send output signals by tacking on an "Output:" string at the end of the title, followed by any outputs that have changed. 

There are drawbacks to this method, most notably the fact that it doesn't sync like mame's broadcast method, so mamehooker could potentially miss a few signals, but it should be good enough for simple leds and the like.

Another method i'm adding is a simple text file monitoring function.  Again, via configuration mamehooker will be able to monitor a text file created by another program and parse in the variables if the "Modified on" date changes. 

I'm also thinking of using the mame source to write an example "mame server" app.  As mame's method is pretty good as well.

Anyway, big changes this upcoming release.  Look forward to it!

[headkaze]

You could use a method like MAME. Create a window, register messages and then communicate back and forth. If you create a dll and a bunch of in different languages then people would likely be more enthusiatic about adding support.

Another method is to use named pipes which is quite simple. Eg. http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp

BTW Are you ever going to move from VB6 to VB.NET?

[Howard_Casto]

I looked into piping....it works, but different langauges have to handle the incoming text differently and it gets a little messy.  Also it seems to be prone to crashing unless you set it up just right.

Actually mamehooker supports command line options as well.  If mamehooker is already running, you can launch it again via the command line with some options and those options will be passed on to the first mamehooker.  It isn't entirely practical for rapid state changing, but for simple stuff (like setting the states of a ledwiz from a controls viewer) it works pretty well.

I like the idea of writing a dll and in terms of mame-style control  "sending output states" it would be fairly easy to implement.  It gets a little messy  when it comes to direct control though (running mamehooker functions directly)... I think there are like 64 functions now and counting, so the only practical way to do it would be something along the lines of a dll function that sends mamehooker the raw string, at which point the dll isn't super useful to the developer.


Regardless, I really do like the way that mame's output system is implemented.  It would really be best if other emulators used it as any apps support mame outputs would instantly support this other emulator.  It's a tad complex though... I think I can stream-line it and maybe that could be turned into a dll.

I dobut I'll ever switch to vb.net, it's the worst of both worlds.  If/When I switch it's going to be to C or a C-based language.  I actually know C pretty well, it's just cumbersome to make forms and stuff with it.. I don't like it for guied apps.  It's hard to switch when vb6 still works so well for most stuff.

Mamehookers staying vb6 for the indefinate future though.... the lack of .net makes for a smaller footprint and it helps on lower-end pcs.  It's bloated enough at this point, it doesn't need any more help. 

[headkaze]

the lack of .net makes for a smaller footprint and it helps on lower-end pcs.  It's bloated enough at this point, it doesn't need any more help.  

These days machines are more likely to have .NET rather than the VB6 runtimes already installed. How is .NET bloated anyway? The runtimes take up a bit of HDD space and that's it.

VB6 and .NET are so similar you shouldn't have a problem with it. I used to code in VB6 and don't miss it at all.

[Howard_Casto]

.net is somehow integrated into windows, much like internet explorer was back in the day.  The reason I know this is because on many of these speedup sites, they reccommend you uninstall .net and install a hacked version instead.  Apparently it can shave up to 15 seconds from your bootup.  Also .net seems to be a "go between" application layer in a lot of instances.  I always call dlls directly from the win api in my apps.


.net has all this schema and collection garbage that annoys me because it isn't really necessary.  It isn't just vb... all the .net visual studio languages seem to be blaoted with it.  I haven't messed with it in a couple of years, but the last time I checked .net actually removes a lot of functionality that I liked.  Just as an example it is now impossible to take a label or image control and give it a transparent background via the properties.  Of course you can still do it, but not without a bit of gdi code. 

[headkaze]

I don't really notice any longer boot times with .NET but I haven't done any tests. I usually need it installed for something though so it's pretty much a given that I'll have it installed.

If you're doing any serious graphics work in .NET you should really use System.Graphics rather than an image or label control. You can set an image or label background to transparent you just need to call SetStyle(ControlStyles.SupportsTransparentBackColor, True) in the form's constructor.

But I guess if you don't like it, you don't like it, and that's fair enough. Anyway I'll stop this OT nonsense and let this thread get back on track.

[Howard_Casto]

Agreed.  

Getting back on topic.  

I wrote a test app for my window title reader and it works amazingly well.... I can manage to keep in sync with a changing window title at 60fps!  It's a tad complex to write a configuration file manually for a game, so I made a little wizard.  Basically you run the emulator/pc game in windowed mode and click on it and the wizard will capture window's title.  It will then ask you two or three simple questions and it will automatically write a configuration based upon the title it found and the info you supplied!

The more I thought about this feature the more useful I realized it was.  You can now launch ahk scripts and helper apps independantly of your front-end, which really cuts down on configuration hassle.  Just as an example my mame cab has a trackball, but it doesn't have any mouse buttons.  This is fine unless I want to run a pc game or two.  With window title detection I could have mamehooker load a generic mouse button remapping script whenever these games are running.  I wouldn't have to write custom scripts for each game nor would I have to worry about having to use different configurations if I ever change front-ends.  It could also be used to exit games.  Mamehooker has keystate detection and one could bind a keypress simulator or a kill process exe to the Escape key.  

Now yeah a lot of these things you can do with wrappers/launchers or from the FE of your choice, but a more universal solution would be nicer and I think this may fit the bill.

After this release I also want to talk to the Daphne guys and see if they approve of letting me add output support to Daphne.  I looked at the source and it would be easy to add it exactly as it is in mame, only there are so few games that the output names and values could be hardcoded, which would simplify the functions significantly.  (You only have one style of scoreboard, three rank lights and a "fire" light.)

Aside from daphne, there are very few arcade emulators that have "unMAMEd" games with outputs.  I think there is supermodel, model 2 and thats about it.  

[headkaze]

Here is a method I used to use in VB6 to communicate between apps. It uses the WM_COPYDATA message to send data between windows. It's pretty simple to use.

[Howard_Casto]

Thanks HK.... I actually use that on occasion myself. 

Anyway sorry about the lack of updates... I got a new el-cheapo tablet and I've been messing with it.  It's decidedly low-end, but for mamehooker that is a very good thing.  I can test my ideas about remote viewing on it and if they work on it they'll work on just about anything. 

Also android apps don't seem to be terribly hard to build.  It appears that unlike most low-end oses, gingerbread actually has apis that you can use.  All I need to be able to do is display text, images and possibly webpages, so I might just make an app.

But I want to go ahead and finish up this version of mamehooker first.  What I've decided to do is have an option for mamehooker to output a "states" cvs file when running display files.  I figure just about everything else can be handled on the other end.   

[isamu]

Thanks for the updates Howard that is very exciting!

With that having been said, can you tell us how things are going on the force feedback end? Have you managed to complete implementing ffb output for any of the Sega drivers(ie OutRun, OutRunners, etc)? Also, "Bdam" mentioned he was looking into getting ffb output working for the Namco System 22 and Super System 22. Any new progress on that front?

[bdam]

For my part, I submitted the code but it was rejected because it used memory addresses that were part of the MCU's RAM versus its output ports.  It was pretty easy to find them in the proper space; Port 5.  However, in the IO port there's a lot of other data also being written there and I can't figure out the mechanism by which to filter it.  Given the status of MH and the PITA that is compiling MAME on an old Pentium P4 I've lost interest.  I've updated the Output documentation with this info in case anyone else is so motivated.

For what it's worth, people seemed to get all excited about the idea of FFB for Ridge Racer but I see no evidence that these games had a FFB wheel.  Only Rave Racer seems to have this; at least in MAME.

[Howard_Casto]

There's no progress atm.  I mean force-feedback is working just fine in my test build, but it isn't ready to be released. 

Unfortunately even I have real world obligations and lately I haven't had the time to dedicate towards mamehooker. 

I will say this though... I know lots of other people are really excited about steering wheel force-feedback.  I'm not one of those people.  I think it's nice to hook it up and because many people have asked me about it I've been willing to work on it, but seeing as how I don't have a driving cockpit it isn't particularly useful to me. 

Bdam is right btw....  a lot of these games people keep asking about in terms of FF never had it, or at least the arcade versions of the games never had it and/or the dumped version in mame is not the ff variant.  With the exception of sega games, you would be suprised how sparse FF is in arcade games. 


So for now, I can't work on it.  The main bulk of my free time is going towards getting my 92 Camaro back into shape atm.  She's been neglected over the past few years and really needs some tlc.

I WILL get to it though, just not right now.

[Howard_Casto]

Man it's been a while!  But this summer has been a busy one and the power outtages last month pretty much ruined the time I had set aside to work on this. 
Anyway, while the site is down I thought I might work on some of these projects a little. 

I've been working on titlebar detection for mamehooker.  I actually wrote the code for this in early April, but I'm finally getting around to hooking it up.   Detecting when a third party emu is active and what rom it is running is exteremely useful for scripts, ahks and the like as well as my yet to be released "you've got manuals" app. 

I should have that done by the end of the week if I get time. 

Then it's on to (UGH) finally finishing up the force-feedback functions.

[BadMouth]

Then it's on to (UGH) finally finishing up the force-feedback functions.

 

Wish you felt more enthusiastic about it though. 

[Howard_Casto]

I should wait until Apr 1st of next year to release it and have the thing play "never gonna give you up" on your motors when you try to use force-feedback. 

[Howard_Casto]

I did a thorough test of super model's output support.  For the most part it's fully mh compliant, but I did notice that the pause output is named "Pause" instead of "pause".
No big deal right?  Well it kind of is.  Mamehooker automates a lot of universal outputs, like pause into more user-friendly functions.  Mame's orientation output, for example is a mess if read as-is, but I convert it into useable data.  Mamehooker searches for any outputs with the name "pause" and binds them to the OnPause line in your ini files.  The pause function is automatically set when you are doing certain things in mamehooker.

So as of now, mamehooker is treating the Pause output in supermodel's ini files like a traditional output.  The proper solution of course is to modify supermodel's source to use "pause" name instead, but I figure this common typo is going to pop up a lot as other emulators adopt mame's i/o system, so I've also modified mh's source to search for any variant of the word pause. 


Did an initial test of the title bar detection by simply re-routing its functions through the mame functions.  I had always intended on adding support for other emulators so thankfully, the state-detection part of the code is fairly modular.

At first glance it works perfectly.  Mind you it isn't done yet....currently it looks for ini files in the ini folder, and now that multiple emus are supported that could get really confusing real fast.  So I need to add an optional "emu folder" variable to all the ini search routines.  That isn't terribly hard, but I'll also have to do similar things with the script editor and add a drop-down box to select the emulator (aka sub-folder) when trying to load a ini file.  I also want to save the last game/emu ran for script editing.  I personally find it annoying that if you stop mame, the "load current rom" option brings up a blank ini. 

So MAME ini files will still be in "ini" for backwards compatability sake, supermodel will be in "ini\supermodel\" and any title bar inis will be in their own respective sub-folder. 

I haven't decided if the default.ini is going to be global for all emulators or not.  I could see it causing problems.  For example if you are using the "mamestart" line of the default.ini to load cpwizard/johnny5 that works great for mame, but other emulators don't have a controls.dat, so it would cause problems.  I've got to think that there aren't a whole lot of things a person would want to do every time the emulator starts/stops regardless of what emulator is loaded. 

I would like opinions on this though.

[BadMouth]

Supermodel is between official releases.  The outputs weren't hooked up in the last official release.

I'm sure that Nik was the one that hooked up the outputs and wouldn't have any qualms about changing "Pause" to "pause".

[Howard_Casto]

I signed up to their forums and made a post about a couple of things I would like to see, so hopefully he'll see it. 

On a slightly related note I think something is wrong with my home email address.  It has an underscore, which I think throws some automated systems off a bit, but I've noticed when I signed up for their forum as well as a couple of others I never got my activation email, even if I requested a re-send.  I'll have to contact my isp to see if they've implemented some server-side filtering or something, but in case somebody has tried to send me an email and I didn't respond(that is NOT related to TDK's current broken state) it could be that my email addy is having issues, so please just PM me here.

I implemented the feature about remembering the last game loaded for editing ini files.  I must say, it's a marked improvement in terms of functionality.

I'll get to the modifications for emu-specific folder later this week if I get a chance. 

[Howard_Casto]

Implemented Emulator Detection. 

I'm hoping the supermodel guys heed my request and change its window's caption to "SUPERMODEL" insted of "SDL_app" but for now at least, upon "mame_start", mamehooker reads the class name of the currently running game and set's things to "MAME" mode if the class is "MAME" and "SUPERMODEL" mode if it isn't. 
It also takes into account the fact that "mame_start" could have been called via the new title bar detection and sets up some things manually if that is the case.

Before the official release I'll nix the hard-coding of class names and instead read this stuff in via a csv file, but for testing this will do. 

Next up is to change all the ini-loading routines to inject the emulator name into the path if it's a non-mame emulator. 

[Howard_Casto]

I actually think I've got all of that stuff implemented.  There is a lot of stuff that could go wrong though, so some further testing is required. 

But I'm ahead of schedule for a change, and that NEVER happens.    I think I'll take a break for a day or two and pick it up later on. 

[Howard_Casto]

Added a wizard for making title detection entries. 

I tried to make it as idiot proof as possible.  It basically asks you to click around in the emulator window and figures most of the info out itself and then asks you a few questions to finish up. 

I can't believe I'm actually making progress at this point.  Hopefully we can have another release soon.

[Howard_Casto]

Man this is getting scary, we might be dangerously close to a release. 


I hooked up the tweak file section this morning, the thing that's been holding back releases for almost a year now.  Mind you I still have to actually test it, so it'll be a while, but the function is complete, so that's progress!

The next version of Mamehooker is going to let you load and use custom force-feedback effects on your ff devices.  Tweak files are the companions to that.  Rather than simply controlling direction and force, you'll now be able to control EVERYTHING in regards to an effect.  Tweak files are kind of like regular mamehooker ini files.  You can bind a specific ff variable to an output or variable. 

of course even after I get it done and working, there is still tons to do.  I'll have to add it into the function wizard and document the thing. 

I think we are long over-due for a source release as well.  The source is an unholy mess at this point, but I can't keep using messy source as an excuse to hold back a release.  I might not do this forever ya know. 

[brad808]

The next version of Mamehooker is going to let you load and use custom force-feedback effects on your ff devices.  Tweak files are the companions to that.  Rather than simply controlling direction and force, you'll now be able to control EVERYTHING in regards to an effect.  Tweak files are kind of like regular mamehooker ini files.  You can bind a specific ff variable to an output or variable. 

Could you explain in a little more detail what a custom force-feedback effect would be and what exactly this means for an end user?

[Howard_Casto]

Think hlsl for force-feedback.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb153254(v=vs.85).aspx


If you are using a simple gamepad with rumble motors, it probably won't concern you.  If on the other hand you are using a ff wheel or joystick, it gives you a lot more options.

[Gray_Area]

I never thought of customizing FFB. I thought people would just go with whatever the game offered.

Howard - have you thought of the ramifications of this??  This could be big in the sexual prosthetics business!

No compensation is required. Just mention my name in your credits.

[Howard_Casto]

Well I'm not customizing FFB.  The games in mame don't have "true" force-feedback and thus some conversion to a Microsoft-compatable format is needed. 

Since every device is a little different, it's just easier to expose all the options I would normally set internally into a settings file, so users have full control.  There are like 80 or so individual options for a FF effect and you can have multiple effects per motor and per device.  Writing a traditional Mamehooker function for the user just wouldn't be practical in this instance, there are too many options.

Now yes, the tweak files allow mamehooker to alter the effect on the fly, but DirectInput is setup so that you can do this, so I'm not hacking DI or anything. 

FF Effects files are nothing new either.  It's an official Microsoft file format that can be loaded automatically by direct input.  Most of your big-time racing sims use FFE files, but not much else as true force-feedback devices are a rarity.

So no, I'm not altering the effects of a FF compatable game, I'm CREATING FF effects for mame, which doesn't support them.  Big difference.

That doesn't mean that you couldn't alter effects for a pc game on the fly, you can, but the game has to capture the joystick in non-exclusive mode.


As for the suggestion, you might want to try googling it.... there's some wierd products out there. 

[Howard_Casto]

Well it looks like the tweak files are working, or at least they worked on the single FF device I have. 

I'm going to have to clean things up a bit before even thinking about a release.

[retrorepair]

Great work as ever Howard 

If you need someone to test on a ffb wheel let me know.

[isamu]

The next version of Mamehooker is going to let you load and use custom force-feedback effects on your ff devices.  Tweak files are the companions to that.  Rather than simply controlling direction and force, you'll now be able to control EVERYTHING in regards to an effect.  Tweak files are kind of like regular mamehooker ini files.  You can bind a specific ff variable to an output or variable.   

That is great news Howard. But I have a clarification question about this....

Does this mean that if I play a racing game with my FFB wheel, but the game DOES NOT have any FFB effects whatsoever, can I use mameHooker to deliver a "virtual center spring" effect to my wheel, so that it doesn't feel all loose and sloppy? That is the one thing I'm hoping, as my wheel it virtually un-useable with mame racing games at the moment. Would be nice to have some spring tension to it.

In addition, have you gotten FFB support working for the Namco System 22 hardware yet? Any support for Ridge Racer or Rave Racer?

[BadMouth]

In addition, have you gotten FFB support working for the Namco System 22 hardware yet? Any support for Ridge Racer or Rave Racer?

They didn't have any force feedback to begin with. 

Very few driving games that are fully playble in MAME did.
Pretty much just the cruisin' series, california speed, & SF Rush.
I'll have to look up the Gaelco games that became playable around the time ridge racer did.

[Howard_Casto]

Actually I don't think the Rush series has it either.  Mind you it's been ages since I've played em in the arcade, but I remember that they used "but thumper" speakers for ff effects... which isn't exactly the kind of FF that translates well to a wheel. 

[Howard_Casto]

Interesting....

I wonder if there is a mid-grade cabinet then because I'm fairly certain that the ones I used to play didn't have it, and this arcade had a few of the sequels as well. Of course they could have just been broken... it wasn't exactly the hey-day of arcades when they were around.   

[isamu]

In addition, have you gotten FFB support working for the Namco System 22 hardware yet? Any support for Ridge Racer or Rave Racer?

They didn't have any force feedback to begin with. 

Very few driving games that are fully playble in MAME did.
Pretty much just the cruisin' series, california speed, & SF Rush.
I'll have to look up the Gaelco games that became playable around the time ridge racer did.

Hello Badmouth. I would be interested in knowing where you got your information regarding the Ridge Racer games not having force feedback? I remember playing the original RR game when it first came out in the arcade in 1994 or so, and remember the wheel delivering some sort of feedback. It was a deluxe sit down cabinet. Or perhaps my mind's playing tricks on me? If it doesn't have FFB, what  exactly kind of wheel did Namco use on their cabinets?

Well, In any case, I *DO* know for a fact that Rave Racer has it, as evident in the service menu.

[BadMouth]

Interesting....

I wonder if there is a mid-grade cabinet then because I'm fairly certain that the ones I used to play didn't have it, and this arcade had a few of the sequels as well. Of course they could have just been broken... it wasn't exactly the hey-day of arcades when they were around.

Must have been broken or a conversion.  There's no mistaking anything else for the green plasticky SF Rush cab.

The CP below the steering shaft is notched out to allow the steering wheel and feedback motor assembly to swing down so it can be serviced without taking anything apart.

Hello Badmouth. I would be interested in knowing where you got your information regarding the Ridge Racer games not having force feedback? I remember playing the original RR game when it first came out in the arcade in 1994 or so, and remember the wheel delivering some sort of feedback. It was a deluxe sit down cabinet. Or perhaps my mind's playing tricks on me? If it doesn't have FFB, what  exactly kind of wheel did Namco use on their cabinets?

Well, In any case, I *DO* know for a fact that Rave Racer has it, as evident in the service menu.

I'm getting my info from the service manuals and shopping for parts when building my driving cab.  RR1 & 2 had spring loaded centering.
I hadn't looked at the Rave Racer manual and have never played it in an arcade. It does show a ffb adjustment in the service menu.
Odd thing is that in the Rave Racer conversion kit manual, it says the feedback settings aren't applicable to RR1 machines...implying that they are to RR2.  I looked at some yellow RR2 dashboards in person at an auction and there was no ffb, just a centering spring.  Now I'm curious as to what type of ffb setup Rave Racer had.  I'll post if I find anything.

[Howard_Casto]

Yeah that's definately it.  It's hard to miss considering how ugly the damned things are.  Also who makes a seat out of hard plastic?  I remember about breaking my butt the first time I sat in one of those!

[isamu]

I'm getting my info from the service manuals and shopping for parts when building my driving cab.  RR1 & 2 had spring loaded centering.
I hadn't looked at the Rave Racer manual and have never played it in an arcade. It does show a ffb adjustment in the service menu.
Odd thing is that in the Rave Racer conversion kit manual, it says the feedback settings aren't applicable to RR1 machines...implying that they are to RR2.  I looked at some yellow RR2 dashboards in person at an auction and there was no ffb, just a centering spring.  Now I'm curious as to what type of ffb setup Rave Racer had.  I'll post if I find anything.

Very interesting. It's been sp long since I played the original RR, that it may in fact be the case that I am simply remembering things wrong. If it only has a spring loaded wheel and no ffb effects, then consider my mind completely blown! Here I am thinking all this time the Ridge Racer supports ffb. Oh well, we can safely say *Rave* Racer supports it, so it's all the more reason to hope for System 22 Rave Racer FFB support in MameHooker one of these days. Let me know if you find any more info.

[griffindodd]

I wrote a test app for my window title reader and it works amazingly well.... I can manage to keep in sync with a changing window title at 60fps!  It's a tad complex to write a configuration file manually for a game, so I made a little wizard.  Basically you run the emulator/pc game in windowed mode and click on it and the wizard will capture window's title.  It will then ask you two or three simple questions and it will automatically write a configuration based upon the title it found and the info you supplied!

The more I thought about this feature the more useful I realized it was. 

Now yeah a lot of these things you can do with wrappers/launchers or from the FE of your choice, but a more universal solution would be nicer and I think this may fit the bill.

Hi Howard.

Mamehooker is great, I use it on my Revolution cab to display Marquees and control panels on a backglass monitor when playing games in Mame and it looks and works really slick.

On my next build, a VPin, I'm going to be using screens on the sides of the pinball cabinet with the intention of showing side art/marquee art on the screens. The plan is to use HyperPin as the FE and Visual/Future Pinball as the Emulators. Is there currently a way to use MameHooker to display an art file/display file that will change when viewing tables in the HyperPin FE and Playing them in the different Emulators? If I could do this then basically the entire pinball machine's skin would change depending what you were looking at or playing.

Great work!!

Joel

[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!