NRage Input Plugin V2.00 BETA (an overhaul)

[rabiddeity]

OK here's the skinny. First, I found another version and discovered basically you broke the pak thing somewhere between Aug 17 and Aug 28.

I have to "unplug" the rumble pak first then switch to mempak to be able to have the game recognize the mempak as I've stated before.

The release version does not work but I did manage to get the new debug to work. Basically, if you go into the config and "save" or "use" while rom is opened, then you're toast. If you just start the rom and never go to the config then it works fine-you can use shortcuts all day long at approp. spots. But this of course defeats the purpose of a lot of things in there: the shortcuts, picking out mem files, "use" button, etc.

A workaround is to go to config, switch to mempak, select right mempak for the game you are about to play, then go back to rumble pak, then save, then start rom and use your shortcut keys to your hearts content. Obviously, not convient in the least but I'm sure you can fix it now that you know what the problem is. The paks seem to switching properly (only in new debug), but its something to do with the "use" or "save" in the config that screws things up. This is the case with 1964 and PJ64. Good Luck!

Alright, I've looked through the code and found a few places I've changed things. Again, this is just with the debug release. Are you saying that if you go in and hit Use/Save while running, the mempaks/rumblepaks stop working completely? Or it only stops working after you Use/Save and then try to switch with shortcuts? If it's the first issue, then it's a problem with moving the control structs over. If it's the second issue, then it's a bit more complicated.

 

[Legend]

The first one. All I have to do is go to the controller pak TAB and that will cut off the paks completely for me.

If I start F-zero, go in game, get rumble then go to config and THEN to the controller pak tab, the rumble will cut out before I even hit save or use and stay that way.

 

[rabiddeity]

The first one. All I have to do is go to the controller pak TAB and that will cut off the paks completely for me.

If I start F-zero, go in game, get rumble then go to config and THEN to the controller pak tab, the rumble will cut out before I even hit save or use and stay that way.

Ahh, then it appears to be not a shortcuts problem but an interface problem... interesting. Now this is useful information. I'll get back to you.

Siskoo emailed me a French translation while I was away, and I've just gotten around to uploading it. Take a look here, or grab it off the first page.

Ahh crap, forget that. Rumble cuts out because the interface acquires the rumble device in exclusive mode (so it can test). If you hit Cancel, the rumble should come right back as the main emu window reacquires the rumble device. Right?

 

[Poobah]

Would you like me to add tooltip functionality to the plug-in for you?

 

[Legend]

Ahh crap, forget that. Rumble cuts out because the interface acquires the rumble device in exclusive mode (so it can test). If you hit Cancel, the rumble should come right back as the main emu window reacquires the rumble device. Right?

Umm...no. ONCE I hit the controller pak tab, the rumble is forever gone, no matter if I hit Save, Use, Cancel or "X".

 

[rabiddeity]

Alright, it's probably not letting go of the handle properly when it goes into config. Does Test Rumble work OK when this happens? I updated the debug release but there aren't many significant changes.

Poobah: let's hold off on adding any more features until I can get a stable 2.00 release. I updated the source to remove UINT16 and INT16 refs.

 

[Poobah]

I think you forgot to change "typedef const BYTE *LPCBYTE;" to "typedef const unsigned char *LPCBYTE" in settings.h. (Remember that windows.h isn't included at that point in the file.)

 

[rabiddeity]

Done. Check the latest source.

 

[Legend]

Alright, it's probably not letting go of the handle properly when it goes into config. Does Test Rumble work OK when this happens? I updated the debug release but there aren't many significant changes.

Test rumble works. New version does not have anything fixed.

 

[Poobah]

Done. Check the latest source.

Are you sure you have updated it? Line 44 of settings.h still hasn't changed.

(Could you also replace the spaces in the file names with underscores?)

EDIT: Could you please also include <stdio.h> in Interface.cpp?

 

[rabiddeity]

Sorry about that Poobah. Forgot to hit "save" on the settings.h file. Removed the space in the NRage filenames. Edited includes to match. Removed an obsolete io.h include from GBCart.cpp since we're not using stdio read funcs anymore, so let me know if that causes problems.

Legend, I went and got a copy of F-Zero X and I'm gonna play with it myself tonight, with the debugger. Sorry to let this drag on so long.

 

[Poobah]

It finally compiles without modifying the code, now. I'll write a makefile and post it later.

For some reason, the ones that I am compiling in MinGW are producing blank message boxes with MB_ICONERROR icons. The execution is reaching line 581 in DirectInput.cpp, but for some reason, the messagebox text is all blank.

The most recent build that you have uploaded was from about eight days ago, so do you think you've broken something?

 

[rabiddeity]

Are you compiling with _UNICODE and UNICODE defined? Also, are you compiling in the resources from the .rc file? If you don't, it will crash when it tries to LoadString. I can recompile to .res format if that would help. Also, for now make sure you don't have any satellite language DLLs installed, as it will just make things more complicated. I can check your compiled DLL to make sure it has all the resources in the correct format, if you want.

However, if execution is reaching line 581, we have worse problems; it means we're not able to load the directinput driver. I haven't changed this code since 1.83 and I doubt it's been changed since the 1.7 line, so you might be on your own here. First let's see if the dialogs will work.

 

[Poobah]

Yes, the UNICODE constants are defined. Perhaps it does have something to do with the resource file. I'll try recompiling it with Microsoft's resource compiler.

EDIT: The same problem is occuring when using the MSVC resource compiler.

 

[rabiddeity]

Send me your .dll file so I can see for myself.

 

[Poobah]

I've attached a solid 7-Zip archive containing the debug and release versions.

 

[rabiddeity]

Hmm... the resources are all there, and in the right places. Some problem with the dynamic loader maybe, I'll check it again when I get back home.

 

[squall_leonhart]

what program you using poobah and is it free lol.

is there any free versions i can use to check the source out?

 

[Poobah]

Do you mean compilers and IDEs? I'm using MinGW and the Code::Blocks IDE.

Here are the MinGW packages you'll want to download. Make sure to get them from MinGW's source forge file listing rather than the HTML table on their site, because it's not up-to-date:
mingw-utils
binutils
gcc-core
g++-core
gdb
w32-api
mingw32-make
mingw-runtime
DX8 SDK (MinGW)

I hope that helps. If you download Code::Blocks, then you'll be able to open up the MSVC projects with it, otherwise you should use the makefile that I've attached.

(Keep in mind that this plug-in doesn't seem to work when compiled with MinGW, for some odd reason.)

 

[rabiddeity]

Well I fixed the config-kills-rumble issue. Rumble will be disabled while you're in the config panel, but this is by design. While in the config dialog, if the emu is still running, any reads or writes to the controller pak return "uninitialized" (just as in 1.83). As soon as the configuration box is gone, rumble should be back. But somewhere along the way I broke test rumble on my machine. It shows up as DI_OK, but nothing rumbles. Maybe it's time for me to get my head examined.

In any case, it needs another round of testing. I've migrated changes to both release and debug, as well as the source.