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