Mame: force direct input without compiling [SOLVED]

[kasty]

UPDATE: now you can simply download the attachment, unzip it in your mame or mameui folder, and execute. Wait 10-30 seconds.
The original post follows, you can use it as reference to manually patch the mame executable.

====================================================

Hi,

when I tried to use mame just with my controller, without the need of a keyboard, I realized that some keys cannot be mapped to the controller's buttons. Not even with joy2key. In order to make it work, everybody suggested to re-compile mame source code replacing "#define FORCE_DIRECTINPUT   0" in src/osd/windows/input.c to "#define FORCE_DIRECTINPUT   1". That works, but it's a little cumbersome, specially for people without a programming background (you need to setup the MinGW compiler and all that stuff).

After inspecting the source code, I realized that we can easily force rawinput_device_create() to fail and return NULL without recompiling. We will attack this lines:

Code: [Select]

// if this is an RDP name, skip it
if (_tcsstr(tname, TEXT("Root#RDP_")) != NULL)
goto error;


As you can see, we can force an error if we replace the second argument to _tcsstr() with NULL. In order to do so, follow the instructions (they should work for Windows, Linux, Mac and any other system):

1) Open the Mame or MameUI executable with any hexadecimal editor. There are tons of free options out there.
2) Find the string "Root#RDP_" (try to find it in Ansi and Unicode). If your text editor doesn't support string searches, try in hexadecimal: Ansi hexadecimal "52 6F 6F 74 23 52 44 50 5F" or Unicode hexadecimal "52 00 6F 00 6F 00 74 00 23 00 52 00 44 00 50 00 5F 00").
3) Once you found the pattern, simply replace it by hexadecimal zeros and save the file. Note for non-programmers: don't confuse the 0 (zero) character with the 00 (hex zero). We need hex zeros here.

Next time you run the mame or mameui executable, direct input will be forced, meaning that you can use joy2key and similar programs to map keyboard keys to your controller's buttons. Tested with mame and mameui 154.

Good luck!

[EMDB]

People without a programming background can't re-compile but should use a hex editor to directly alter the machine language!? 

[kasty]

EMDB: see the new attachment. Even you can do it now.

Enjoy.

[EMDB]

I'm sorry but I DO have a programming background so I rather recompile 

[empardopo]

I think It's very interesting!
Thanks!

[SegaOutrun]

i just google the keywords mameui64 [release number] dinput nonag and there plenty of places that have them precompiled.

[klala]

1) Open the Mame or MameUI executable with any hexadecimal editor. There are tons of free options out there.
2) Find the string "Root#RDP_" (try to find it in Ansi and Unicode). If your text editor doesn't support string searches, try in hexadecimal: Ansi hexadecimal "52 6F 6F 74 23 52 44 50 5F" or Unicode hexadecimal "52 00 6F 00 6F 00 74 00 23 00 52 00 44 00 50 00 5F 00").
3) Once you found the pattern, simply replace it by hexadecimal zeros and save the file. Note for non-programmers: don't confuse the 0 (zero) character with the 00 (hex zero). We need hex zeros here.

Hi. I want enable this in mame32k 0.64, but string "Root#RDP_" does not exist. How to enable autohotkey in this mame32k 0.64? Thanks.

[spelosi]

Thanks to the original poster!

I made use of your patch this afternoon and it worked flawlessly on mame 143.

I'm using an old version of mame because the romset I have is for that version and it works well enough for me.

I was copying my mame configuration from my cabinet to a PC for my son. I have custom configs for many games and did not want to remap them all to joystick controls.

When joytokey (which we use for many different applications) wouldn't work I went to google.

I have experience compiling mame, but the last time I did it was more than 3 years ago. I did not want the hassle, so I tried your tool.

Thanks again!

[headkaze]

Having a quick look at the Raw Input setup in MAME:

Code: [Select]

// look up the entry points
register_rawinput_devices = (register_rawinput_devices_ptr)GetProcAddress(user32, "RegisterRawInputDevices");
get_rawinput_device_list = (get_rawinput_device_list_ptr)GetProcAddress(user32, "GetRawInputDeviceList");
get_rawinput_device_info = (get_rawinput_device_info_ptr)GetProcAddress(user32, "GetRawInputDeviceInfo" UNICODE_SUFFIX);
get_rawinput_data = (get_rawinput_data_ptr)GetProcAddress(user32, "GetRawInputData");
if (register_rawinput_devices == NULL || get_rawinput_device_list == NULL || get_rawinput_device_info == NULL || get_rawinput_data == NULL)
goto error;
You could just replace "RegisterRawInputDevices" with NULL's and it will satisfy the "register_rawinput_devices == NULL" check. Could be more backwards compatible this way.

Actually if you replace it with "***DISABLE_RAW_INPUT***" you could always replace it back with "RegisterRawInputDevices" to turn Raw Input back on.

[wmoecke]

I am setting up a PC with Hyperspin as a personal arcade machine, and after A LOT of trial and error, I found MAME v0.137 to be the best match for my romset (but not without a heavy load of fixing a good deal of my 189 roms by hand (taking individual files from other romsets I have and combining them)

Then I came to this issue - JoyToKey is my app of choice for handling joystick to keyboard affairs, and I've spend a good deal of my time setting it up correctly for all my emulators.
I have to say, even with a solid programming background I found out that compiling MAME is a daunting task (to say the least). Even following MameDev's official instructions went into nothing - after getting error after error after error from the MinGW compiler, and finding next to no tips for solving these issues - even tried using @headkaze's Mame Compiler 64 (first the 1.17 version, then the most recent). Seriously. I even came to the point of disassembling his executable with a .NET dissassembler and looking into the CompileMame() and GetMameParameters() functions to figure out the command-line parameters it was using, to no avail at all. That's how bad I wanted this to work.


So I found that the EASIEST WAY is to really open the .exe with a hex editor and find the string pattern then replace it with null, following @kasty's instruction.
I found some people are saying that this would be "too difficult for non-programmers". I challenge that statement. Anyone with the ability to edit a .ini or .xml file can do this. All it takes is to download the appropriate editor (heck, even NP++ has a plugin for that). And for those who also say that they'd "rather recompile", I bid you "good luck". I've given up on that. The way that REALLY works WITHOUT complications is @kasty's. I say direct edit is THE way to go (even the patcher provided by the original poster didn't cut it).

So thanks to @kasty. You saved the day, bro. And I learned a bit of the theory and practice of patching executables in the process. Whaddayaknow? 

[headkaze]

I found out that compiling MAME is a daunting task (to say the least).

Compiling the latest version of MAME using MAME Compiler is as easy as pressing the GO! button*. Compiling older versions of MAME can be problematic as it depends on what version of MinGW was used to compile it at the time.

* Sometimes the compile will fail due to GCC running on multiple threads but it generally only requires you to try again a few times.

I even came to the point of disassembling his executable with a .NET dissassembler

Why? The command line arguments are shown at the beginning of the compile.

Compiling is still useful for removing the warning screens so there is no need to scare people away from it. It really is very simple.

[wmoecke]

Compiling older versions of MAME can be problematic as it depends on what version of MinGW was used to compile it at the time.

Exactly my case. Mame v0.137. I could get the sources (thanks to the link at the very end of your homepage) but my suspicion is that the MingW GCC compiler I got was possibly more recent than the one the MAME team must have used back in 2010.

The command line arguments are shown at the beginning of the compile.

Really? Care to point out exactly where this information should be output? 
v1.17 - console output

* I shall point out that what I wanted to see is which actual command was being issued to start the compilation process (since the current mamedev page instructs that using 'make' while being within the source directory should do it - but that doesn't work for old MingGW as the build executable has a different name and I wasn't aware).
* And it doesn't matter how many times I click the GO button - I always get the same error at the console output.
* I can even recall during my search I've found some old forum where someone's asking you a question regarding this exact same error; however it seems they never got a reply. I just can't figure out how to bring up that URL on Google again.

BTW - further research indicates this error message in your app's console appears to be related to the way its spawning a child process to get the compiler output redirected to the console window. I noticed after reading this thread that launching the compiler through a command prompt in Windows doesn't give that error (however, then I get to other error messages issued by the compiler - likely due to the reason explained above)

Compiling is still useful for removing the warning screens so there is no need to scare people away from it. It really is very simple.

I found that removing the nagging dialogs I was having (e.g., the 'exit' confirm dialog - I really haven't noticed any other nagging screens on mame v0.137, with the exception that on newer versions, there seem to be "loading" messages at the start of loading a rom, which do not bother me at all) was as simple as editing the mame.ini file and setting a parameter to 0 - No need to recompile for that.
And due to the reasons explained (3 days wasted trying to figure out how for the life of me, to compile mame v0.137 without any progress as opposed to 10min of hex editing a file to finally get the executable to comply to 'fake' keyboard input issued by JoyToKey - something imho, wouldn't hurt if the MAME team considered adding a command-line switch for), I'd rather NOT recompile; there's simply no compare. Theory vs. practice.