Main Woodworking Reviews Software Monitor/Video Maximus Arcade
Audio/Jukebox/MP3 Project Announcements Artwork Consoles Buy/Sell/Trade Meet Up
Arcade Miscellaneous Everything Else Politics n Religion Forum Discussion Wiki Discussion GroovyMAME
DOS/WinCab Merit/JVL Touchscreen Automated Projects Driving & Racing Project Arcade Old Boards
Linux Restorations Pinball MaLa Frontend controls.dat Old Archives
    Retail Vendors    

Unread posts | New Replies | Recent posts | Arcade | Rules | Chatroom | Wiki | File Repository | RSS


  

Author Topic: Mame Hooker 4.0 FINALLY Released!!  (Read 4973 times)

0 Members and 1 Guest are viewing this topic.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Mame Hooker 4.0 FINALLY Released!!
« on: May 31, 2011, 05:27:44 am »
Tons of bug fixes, a metric ton of new features, brand new, built-in INI file editor, new tutorials.... ect.

This build is pretty damn awesome if I do say so myself and the sheer scope of it's awesomeness will be revealed as I churn out tutorials.   ;) ;)

As usual, a full writeup is on my site, so download and enjoy. 

http://dragonking.arcadecontrols.com/index.php

Also please let me know about any bugs.  What has delayed the release so long as been bug testing, but with all the stuff I've added there are bound to be a glitch or two in there. 



bdam

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 37
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #1 on: May 31, 2011, 05:38:42 pm »
Excellent work Howard.  The good news (for me at least) is that now MH detects my wheel.  The bad news is that the DirectX stuff still doesn't work.  To be fair, you said that might be the case.  If/when you release the source I'll take a look to see if I can figure it out.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #2 on: May 31, 2011, 06:46:34 pm »
Good to hear that we are at least moving in the right direction. 

The source will probably come out this coming weekend, but no promises as I have relatives coming in. 

The hold up is that I actually removed a good portion of code and I need to take that out of the source so people don't get confused.

bdam

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 37
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #3 on: June 01, 2011, 11:10:46 pm »
After a couple of days working with the new MH, a few thoughts if you're open to comments from the peanut gallery.

It seems that I can't create a log file anymore.  I select 'Start Log file' and it doesn't change to 'Stop Log file'.  If I click it anyways I still don't end up with a log file.

Out of interest, why Hex display?  In looking for outputs I've found myself writing a ton of calls to display a byte as individual bits.  A binary display would save a bunch of time trying to find the one or more bits that are of interest.

Lastly, and this might just be due to my POS machine at the moment, but when I have a lot of outputs getting triggered fast the debug window gets bogged down and can become unreadable.  It just can't keep up with refreshing 20+ lines at speed.  Is that just me or do you see that too?  I was wondering if the use of a datagridview might help by just updating the relevant cells instead of a whole text blob.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #4 on: June 02, 2011, 02:19:27 am »
I'm suprised I left the log file in... I thought I had gotten rid of it.  It's completely useless for debugging, I tried to tweak it a bit, but it wasn't helpful.  I'll either fix it or remove it next release.  I want to fix it, it's just that logging every change makes for a text file a mile long when you are working with strobing data and thus it turns out to be fairly useless when writing drivers.  I can't settle upon a happy medium.


Show hex is useful because if you go into a lot of the test menus for games, particularly racing games, the value of the motors are typically 0 to FF.  Also mame drivers generally handle numbers in hex as well.  I could add binary, but my guess is it would confuse the hell out of people.  It might slow down the refresh speed as well.  There are built in functions in Vb to convert a number to hex, but outputtting binary numbers would require a custom function that would probably be quite cumbersome and slow.

Datagrid DEFINATELY won't help.  If you want your machine to lockup then I can add datagrid.  ;)  I specifically use a text box because it's the quickest control to update.  If you mean lockup as in "the window turns gray and doesn't respond" then no, I've never seen that happen, but if you mean that sometimes it doesn't refresh in a timely manner or refreshes so fast that you can't see the change then I've ran across that before. 

I just tried outrunners, and terminator 2 to make sure and aside from a little bit of flicker on term2 (it's quite literally the fastest output in mame so far) they both updated fine. 

You need to keep in mind that most of these outputs fire so fast that they shouldn't be readable by the human eye at all.  The debug window should give you a general idea of what is going on, but unless the game is paused, I don't think it can be trusted to give you a rock-solid, in-sync, status update.

You know, I started development of MH on a fairly slow machine.  Just out of curiosity what are you running?

I have experimented with a lot of different controls to try to churn speediness out of the debug window and I keep coming back to the text box.  It isn't perfect, but it gets the job done. 

bdam

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 37
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #5 on: June 02, 2011, 08:58:11 am »
My main machine died late last year and I've been stuck with a P4 2.something Ghz with 512Mb of RAM that I was throwing out at work; everything I mentioned probably comes out of this.  I can't tell you how much I wish I had caught this bug a year ago or a year from now.  Compiling takes 5+ minutes so I tend to pile on a bunch of outputs in different write handlers to try and see which are firing in relation to output tests.  Then I'll create 8,16,or 32 individual outputs for the bits to see which of them are involved.  It always seems to come down to the bit level and when there's multiple outputs in the same byte I've found it best of show each bit individually.  This is where binary display would save me a whole bunch of time and a lot of lines in the debug window. 

I'll agree the log file can be frustratingly long and can really bog everything down but I've found it indispensable in a few of the driver's I've been working on.  Like you say, some of the data goes by faster than you can ever hope to catch by eye so your only hope is to log it and review it later.  Then there's the situations where you need to pick out more than just the raw data but also a pattern of data in the same byte.  Not a big deal, I can still use 3.7 for this, but unless there's a better way to pick this stuff out it would seem to be a big loss to not have logging.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #6 on: June 03, 2011, 04:56:11 am »
Yeah I doubt the processor is hurting you, but the 512 mb of ram probably is.  Hell I think mamehooker takes up around 8 megs just by itself at this point when it's active. 

That's exactly how I do it, so you will have good success by using that method.  ;)

Even with a binary conversion, I dunno if it would be helpful because it wouldn't be a fixed number.  If the integer value of the byte is first 1 and then 512, you are going to get the bianry numbers of:



and

1000000000

Seeing those two flickering between each other might be more difficult to track than the integer values.   Now sure, I can add a fixed value, but how would I know what fixed value to use?  Some outputs in mame right now are two bytes in length.

I will look into adding it though.

We are probably going to get an interum "bug-fix" release just prior to the source code.  That's one of the reasons I waited to post it... you always find little things.

 


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #7 on: June 03, 2011, 04:57:36 am »
In other news tutorial #3 is up!  This one is very important for noobs as it explains how to bind multiple functions to an output and how to have different functions for each value. 

bdam

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 37
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #8 on: June 03, 2011, 08:04:25 am »
>it wouldn't be a fixed number
Yea, I had thought about that.  This feature would be useful to exactly two people in the world right now, you and I.  So if you want to just base it on 8 or 16 bits then just do that and we can make sure that we feed it 8 bits.  If you want to bury the option to enable it so regular users won't come across it much that'd work too.  Maybe it'll be useless no matter what you try; it's just a thought.  I've been using MH primarily from an output finding standpoint so when you enabled Hex I thought I'd mention it.

The link to the new tutorial points to the second tutorial (mhsniping).  Damn copy and paste.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #9 on: June 04, 2011, 01:40:58 am »
Thanks for the heads up on the tutorial.  I really need to stop posting those at 3am, but when I can't sleep and it's nice and quiet then I have the urge to write one up. 

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #10 on: June 04, 2011, 02:12:00 am »
Another tutorial is up, this one branches off into the display file section.  It basically tries to teach you about dual monitor theory and the best place to positon your secondary monitor (in windows at least). 

If I get a notion I might go ahead and throw another display file tutorial in there so that you will actually be able to do something with the knowledge, but in all honesty, in terms of the output controlled display files on the site, they are pretty much automatic... download and forget.  I will definately show off some of the more advanced things you can do with display files in future tutorials though.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #11 on: June 23, 2011, 07:24:01 pm »
I just wanted to give a quick update regarding force feedback and wheels. 

Whenever I removed error handling on mamehooker to test a force-feedback wheel it became apparante what the problem was.  Dx8 and vb6 didn't like the fact that there was only one motor actuator (or axis) instead of the typical two.  According to the dx8 sdk, the vb implementation of dx8 supports only two axis.  I assumed that meant that any devices that used more than two had their extra motors ignored.  This isn't the case.  Extra motors are indeed ignored (and why shouldn't they be... multiple axis motors didn't exist when dx8 came out and they are still quite rare) but if you have less than two axis, directx can't create the effect. 

At first I thought this to be some sort of bug, but I tried some visual c examples, the SAME examples I got from the vb section of the dx8 sdk, and they worked. 

The problem?  The DIEFFECT structure of dx8 is automatically defined in vb6 but manually defined in C.  The two structures differ in one area.  In the C version you expose the "number of axis" flag and setup a custom settings structure accordingly, in VB "number of axis" are hardcoded to 2.  At the time this probably made sense.... ff was in it's infancy and microsoft's ff flight sticks were pretty much the only ff devices on the market.  Now we have many variances though. 

The solution?  Well that is a tricky one.  For right now, the solution is to implement the "create effect from file" function into mamehooker.  I can include a custom "wheel" effects file and use it for single axis devices.  Using the "fedit.exe" tool included with the dx8 sdk I can build the c-style effects settings externally and save them to a file, and then load the file instead of creating a effect from within vb and tweak the direction/magnitude.  I've tried this and it indeed works!  It will just take some special case coding on my part to implement properly.  I've wanted to implement this as a stand alone function in mh anyway as it allows you to create more complex effects. 

The long term solution is I probably need to write an override type structure for the default DIEFFECT in vb.  This might get tricky because I don't know the vb equivelent of some of the C data types and/or it would be difficult to convert them. 

I have also learned far more about force-feedback than I wanted to when I started to implement it in mh, so I've decided to get that part of the code a complete overhaul.  So sit tight as a new release with proper ff implementation is on the way!!!

Dudeman

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 228
  • Ecky ecky ecky ecky P'Tang! Zoop-boing mmmzoesm...
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #12 on: November 18, 2011, 12:08:27 pm »
Has anyone ever had any issues running this? I installed it on my TinyXP and it won't run. It just starts and immediately stops. Nothing in the event logs, and I can't figure out if there is any debugging options when you start it. I've checked all the dlls and everything is up to date so I'm not sure what the deal is.


EDIT: This has been resolved. I talked with Howard and it was the TinyXP version I was using. Beast Edition to be exact. I did a repair install of XP and that resolved my issues. Thanks Howard.
« Last Edit: January 05, 2012, 09:16:23 am by Dudeman »

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #13 on: January 03, 2012, 11:32:58 pm »
Howard, I notice mamehooker comes with an xinput dll file. Does this mean that your program allow me to use xinput with MAME? If so, can you please please tell me step by step what I have to do to make mame acknowledge an xinput device? I don't need ffb I just want mame to acknowledge my wheel as an xinput wheel. I've explained why in this thread:

http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=272112&page=0&view=collapsed&sb=5&o=&fpart=1&vc=1&new=1325615296

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #14 on: January 04, 2012, 06:09:43 pm »
No... mamehooker only handles outputs.  The xinput dll is for the rumble feature of the gamepads.

That being said, xinput works in mame just fine.  Simply download the official microsfot drivers for input devices..... they show up as DI devices automatically.

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #15 on: January 04, 2012, 09:51:55 pm »

That being said, xinput works in mame just fine.  Simply download the official microsfot drivers for input devices..... they show up as DI devices automatically.

First of all thank you for the reply Howard and Happy New Year.

OK here's the thing....devices such as the xbox 360 pad DOES work in mame like you said, but MAME picks them up as DirectInput devices, not as xinput. I want MAME to support the Xinput driver natively, so that it will acknowledge the Xinput dll file my friend wrote for me. This dll file allows my steering wheel to tell Windows that it is an Xinput device, not a DirectInput one.

For example, a third party plugin like LilyPad for the PCSX2 Emulator supports xinput. Therefore whenever I run PCSX2, it initiates a beep through my speakers letting me know the dll file was recognized, and thus my wheel works as an xinput device. Since MAME does not pick up my dll file, it means it does NOT contain support for native Microsoft xinput drivers, at all. Thus my dilema.

So I guess my next question is, is it possible to compile a version of mame that DOES contain xinput drivers? That's the million dollar question.

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #16 on: January 05, 2012, 04:19:15 am »
Well I hate to be the one to tell you this, but there is absolutely, positively no point in tricking a DI device into showing up as a XI device as it pertains to mame. 

Directinput offers the exact same functionality is Xinput to the end user.  The only difference is that xinput is easier for programmers to code for.  Since mame already supports direct input, there is no reason to force the device to show up as xinput.  You do understand that xinput devices can show up as xi for some programs and di for others right? 

It sounds to me as if your wheel is working just fine.  It shows up as xinput for pcsx2, which is just fine, but it is really a directinput device.  That is fine too as mame supports directinput devices... you just need to set it up in mame's input settings.

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #17 on: January 05, 2012, 06:33:53 am »
Well I hate to be the one to tell you this, but there is absolutely, positively no point in tricking a DI device into showing up as a XI device as it pertains to mame.  

Directinput offers the exact same functionality is Xinput to the end user.  The only difference is that xinput is easier for programmers to code for.  Since mame already supports direct input, there is no reason to force the device to show up as xinput.  You do understand that xinput devices can show up as xi for some programs and di for others right?  

It sounds to me as if your wheel is working just fine.  It shows up as xinput for pcsx2, which is just fine, but it is really a directinput device.  That is fine too as mame supports directinput devices... you just need to set it up in mame's input settings.

Howard you are correct, my wheel DOES work just fine as a direct input device. But you are also wrong in saying that there is no way to manipulate a device and turn it from a DInput device to an Xinput one.  The reason why I was interested in having MAME acknowledge it as an xinput device is this: Bare with me here.....


I have a force feedback steering wheel and love racing games. The wheel is an ECCI 7000 FFB wheel.

The problem is, my wheel rotates 900 degrees. As a result, playing games that do not support force feedback makes my wheel feel sloppy and without any resistance what so ever.

So...to resolve this, a friend of mine, known as "Racer_S"(a ---smurfing--- talented WIZARD in my eyes) from the x360ce boards wrote a custom dll file for me, that allows me to apply any amount of resistance to my steering wheel as I want, so that it feels like there's a virtual spring inside, giving it that old school arcade "Pole Position" feel. It may not be ffb, but it gets the job done with those games that do not support FFB or do not feature the ability to adjust a center spring effect on wheels.

So... this little xinput dll file comes in VERY handy with most of those programs. But there is a catch....the dll file Racer_S wrote uses the xinput code, and therefore turns my wheel into, you can say, an "Xbox 360" analog device. Any program that supports Xinput right out the box, supports this dll file and thus triggers my wheel as xinput, complete with centering spring effects and all. I can adjust spring tension, intertia, and a host of other things that I could not otherwise do in MAME itself, or even Windows Control Panel for that matter.

If MAME supported xinput, I would be able to use my wheel and apply the necessary spring-like effects to give it just the right amount of tension via my dll file.

Hence the reason I was asking anyone if they know of any version of MAME that supports xinput. Or perhaps a utility that allows any version of MAME to acknowledge and be compatible with xinput. Like I said it's not FFB but it's at least something.


On another possibly interesting note, Howard I noticed you mention in one of your other posts the program called Fedit. I too, am familiar with this program, as it allows me to tweak ffb effects such spring tension, etc for my steering wheel. This gentlemen Racer_S also wrote a custom DirectInput dll file for Fedit, and what it does is allows me to run Fedit in the background while using any other program. So for example, lets say I am in the middle of testing a certain ffb effect in fedit like say, center spring effect.... while this spring effect is activated in my wheel, I can actually click away from the fedit window, start a game, and continue to play the game WITH the spring effect from fedit still activated in my wheel! So any game that doesn't support ffb or contains a center spring strength option, would be no problem since I just run fedit along with my custom made dll and still have the spring effect active.

I was hoping I'd be able to do this with MAME but alas, the effects in fedit goes away upon entering a game in mame. Very very frustrating. Therefore Howard, I was wondering if you can tell me why this is? Why do my effects in fedit stop being felt in my wheel once I start a game in MAME, but works in EVERY other game or emulator I use? I mean, if MAME has support for all things DirectInput, why do the effects in fedit go away? If you know the answer please shed some light on this.

« Last Edit: January 05, 2012, 06:36:22 am by isamu »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 12033
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #18 on: January 06, 2012, 12:24:54 pm »
That's an easy one.... mame supports direct input, it does not support force feedback.  I'm pretty sure it specifically turns it off, if only for a second.


That being said, I've got a FF wheel and the "return spring"  mode works just fine in mame, you've just gotta use the software that came with the wheel as it is low-level and doesn't use DI to set the effect.  So unfortunately I think your problem might be a hadware one. 

The next version of mamehooker will allow you to set custom force feedback effects.  Since it grabs ahold of the device in non-exclusive mode, it can send effects while mame is running.  So just sit tight for that release and maybe it will help you out. 

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #19 on: January 06, 2012, 05:13:00 pm »
That's an easy one.... mame supports direct input, it does not support force feedback.  I'm pretty sure it specifically turns it off, if only for a second.


That being said, I've got a FF wheel and the "return spring"  mode works just fine in mame, you've just gotta use the software that came with the wheel as it is low-level and doesn't use DI to set the effect.  So unfortunately I think your problem might be a hadware one.  

The next version of mamehooker will allow you to set custom force feedback effects.  Since it grabs ahold of the device in non-exclusive mode, it can send effects while mame is running.  So just sit tight for that release and maybe it will help you out.  

Howard thank you very much for your feedback and response. I consider it very valuable in this community.

Just a quick comment regarding your comment about MAME and ffb.....yes MAME does not support it, and you're probably right, maybe it IS deliberately turning off the ffb effect that fedit is delivering to my wheel. But the thing is, this dinput8.dll is supposed to prevent that, and other programs that do not support ffb can be use in correspondence with this file and thus fedit. Strange...

When Racer_S was writing the dll file, he tried to explain the reason why the effects get cut off from fedit. Here's a snippet from the thread:

Quote
it seems that when the window loses focus the program stops the effect and unaqcuires the device. And this FEdit program is using DirectInput 7 so the earlier dll wasnt even loaded. I've edited the EXE to prevent that from happening (with a hex editor) and now it behaves like you wanted it too (tested it with my wheel). The only other thing is what will happen when you launch the game you want it to work with. It may cause some conflicts and either cause an error or take over the device, it will vary with games so you may want to test this in the target game.

Howard, when you get some free time on your hands you can check out the thread where he and I discuss this project, here:

http://www.tocaedit.com/IB/index.php?showtopic=768

It sheds some light on the way windows works in conjunction with how fedit and other programs work. Fedit uses DirectX7, so maybe that might have something to do with it?

In addition, I have uploaded and attached a modified version of fedit as well as the dinput8.dll file so you can try them and see for yourself how this works in 99% of all programs...but not MAME :(

The other thing I'd like to clarify Howard is, my steering comes with the Immersion Touchsense software, and all calibration and force effects are done within that menu(which is contained in the standard Windows 7 game controller settings). You are correct in that the software DOES have a setting for spring, damper, etc, but because my wheel turns 900 degrees, and does *not* have a way to physically adjust the rotational degrees to anything less, the turning strength is very soft EVEN with the spring slider turned all the up to the max. I have discussed this issue with ECCI and they indeed acknowledge that this is normal, and that not having a way to reduce the degrees of rotation was a deliberate design decision on their part. So you can imagine how overcome with joy I was once I discovered fedit, and then shortly after my friend Racer_S(who unfortunately has come up missing at the TocaEdit site for the last year).

Anyway, with all that having been said, I am absolutely delighted to hear this bit of news.....


The next version of mamehooker will allow you to set custom force feedback effects.  Since it grabs ahold of the device in non-exclusive mode, it can send effects while mame is running.  So just sit tight for that release and maybe it will help you out. 

That is great news! But just wondering....will it be like fedit, and allow me to test out forces and have them continuously running infinitely WHILE running mame? And will spring strength, inertia and other ffb effects be adjustable the way they are in fedit? Because if so, that sounds like exactly what I want....right under actual real FFB support for Namco and Sega's driving games of course :p

Can't wait til the next version of MH comes out, and keep up the good work man. I certainly appreciate it :)
« Last Edit: January 06, 2012, 05:41:10 pm by isamu »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2740
  • 0x2b|~0x2b?
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #20 on: January 16, 2012, 07:31:32 pm »
isamu: Mame doesn't use dinput8.dll it uses dinput.dll so try renaming it. If that doesn't work it probably uses an older incompatible version of DirectInput.

Also you have do a custom compiled version of MAME with FORCE_DIRECTINPUT set.

EDIT: I just looked at MAME's verbose output and it says "DirectInput: Using DirectInput 7"

EDIT2: It looks like you can modify the windows.mak makefile to force it to use DirectInput 8

Code: [Select]
ifeq ($(DIRECTINPUT),8)
LIBS += -ldinput8
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0800
else
LIBS += -ldinput
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0700
endif
« Last Edit: January 16, 2012, 07:57:57 pm by headkaze »

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #21 on: January 17, 2012, 04:26:03 am »
isamu: Mame doesn't use dinput8.dll it uses dinput.dll so try renaming it. If that doesn't work it probably uses an older incompatible version of DirectInput.

Also you have do a custom compiled version of MAME with FORCE_DIRECTINPUT set.

EDIT: I just looked at MAME's verbose output and it says "DirectInput: Using DirectInput 7"

EDIT2: It looks like you can modify the windows.mak makefile to force it to use DirectInput 8

Code: [Select]
ifeq ($(DIRECTINPUT),8)
LIBS += -ldinput8
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0800
else
LIBS += -ldinput
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0700
endif

Headkaze...I really appreciate you coming into this thread to offer your suggestions....thank you very much. I am going to try your suggestions when I get some time and see what happens :)

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #22 on: January 17, 2012, 05:07:40 am »
isamu: Mame doesn't use dinput8.dll it uses dinput.dll so try renaming it. If that doesn't work it probably uses an older incompatible version of DirectInput.

Also you have do a custom compiled version of MAME with FORCE_DIRECTINPUT set.

EDIT: I just looked at MAME's verbose output and it says "DirectInput: Using DirectInput 7"

EDIT2: It looks like you can modify the windows.mak makefile to force it to use DirectInput 8

Code: [Select]
ifeq ($(DIRECTINPUT),8)
LIBS += -ldinput8
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0800
else
LIBS += -ldinput
CCOMFLAGS += -DDIRECTINPUT_VERSION=0x0700
endif

OK HEADKAZE question my friend....


I am looking at the windows.mak makefile and that line of code already exists in there. What do i need to change exactly? And once I change it, do I need to rebuild a new compiled version of mame in order for the changes in the windows.mak file to take effect?

Or can  I simply run my *existing* compiled version of mame?
« Last Edit: January 17, 2012, 05:17:31 am by isamu »

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2740
  • 0x2b|~0x2b?
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #23 on: January 17, 2012, 12:34:55 pm »
At the very top of windows.mak you will see the following

Code: [Select]
# set this to the minimum DirectInput version to support (7 or 8)
# DIRECTINPUT = 8

Remove the '#' next to the line to uncomment it, like so:

Code: [Select]
DIRECTINPUT = 8
You may also need to force MAME to use Direct Input, to do that go to src\osd\windows\input.c

And change
Code: [Select]
// For testing purposes: force DirectInput
#define FORCE_DIRECTINPUT   0

to
Code: [Select]
// For testing purposes: force DirectInput
#define FORCE_DIRECTINPUT   1

Now do a clean and rebuild. It should now be built to support Direct Input 8. You can check which version of the dll it's using by running Process Explorer when MAME is running by clicking on it and opening the lower pane view. Check for dinput8.dll in the list.
« Last Edit: January 17, 2012, 12:42:52 pm by headkaze »

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #24 on: January 17, 2012, 07:56:23 pm »
OK well, I just compiled a new build with the changes you suggested and made sure they're properly modified and typed in, and still no luck. FORCE DIRECT INPUT was set to 1 in the input.c file and directInput 8 was forced by commenting out that "#" symbol in windows.mak file

Can you tell me what is "Process Explorer" and where do I find it?

Also, just to be sure, where should I place my dinput8.dll file? Inside the same root directory as mame64.exe correct?

I am thinking it is like Howard said...the dll file stops allowing fedit to grab ahold of my steering wheel in non-exclusive mode once I click to the mame window. Just to be clear, fedit continues to run and deliver the spring effect to my wheel, *only until* I click to the mame window. Then the effects dissapears. Odd, since this dll continues to allow fedit to deliver the spring effect signal to my wheel in EVERY other program I run. So there appears to be a conflict there.

In any case I can't wait till Howard brings out the next MH. :)

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2740
  • 0x2b|~0x2b?
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #25 on: January 17, 2012, 08:02:01 pm »
Process Explorer is the first thing to show up when you Google it.

Yes, you should place the dll in the same folder as MAME's exe.

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #26 on: January 17, 2012, 08:06:35 pm »
OK according to PE, it appears MAME is infact using DI8. In PE, upon clicking on mame64.exe, then clicking on the threads tab, "DINPUT8.dll!DirectInput8Create+0xa4ba" is listed. So I'm assuming that is proper verification.

Not sure what else to try.

headkaze

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2740
  • 0x2b|~0x2b?
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #27 on: January 17, 2012, 08:24:10 pm »
What you want to view in the lower pane is "DLLs". Check for dinput8.dll and double click on it. It will show you the path to the dll it's using. Check it's using your dll.

isamu

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 393
  • I'm a llama!
Re: Mame Hooker 4.0 FINALLY Released!!
« Reply #28 on: January 18, 2012, 02:59:52 am »
What you want to view in the lower pane is "DLLs". Check for dinput8.dll and double click on it. It will show you the path to the dll it's using. Check it's using your dll.

OK got it....lower pane does show the dlls and one of them is in fact a dinput8.dll. Interestingly enough however, is that highlighting and then hovering my mouse over the dinput8.dll file reveals that it's from my windows/system32 folder. The dinput8.dll file my friend created that is located in my mame folder, is *not* listed in the lower pane. Is this normal?

  
 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29