NRage Input Plugin V2.00 BETA (an overhaul)

[Legend]

Ok, I don't think you going to not make your tenative release date, especially with this new BUG!!!

When you switch paks in a game, the rumble never works. I'll give you a scenio.

Start Beetle Racing, go to options, plugin in mempak, select right mempak file, click use, shortcut key to "unplug" then switch to "mempak", let game load save, later when prompted, shortcut key to switch to 'rumpak". No rumble in game.

The whole time the messages are popping up (only using Jabo in windowed) and everything looks as if it's working, but it's not. This of course was not the case in earlier releases. Good Luck!!:arabia:

 

[Poobah]

rabiddeity, on line 144 of International.cpp, you use "GetUserDefaultUILanguage()". This function is only defined when the WINVER macro is greater than or equal to 0x500, so the plug-in can't currently be compiled on Windows versions that are before Windows XP. So, you should change:

		case VER_PLATFORM_WIN32_NT:
			if( VersionInfo.dwMajorVersion >= 5)   // Windows 2000 or higher
				uiLangID = GetUserDefaultUILanguage();
			else {   // for NT4 check the language of ntdll.dll

to:

		case VER_PLATFORM_WIN32_NT:
#if WINVER >= 0x500
			if( VersionInfo.dwMajorVersion >= 5)   // Windows 2000 or higher
				uiLangID = GetUserDefaultUILanguage();
			else
#endif
			{   // for NT4 check the language of ntdll.dll

Also, _WIN32_IE is never defined in a standard MinGW distribution, but it is needed for a lot of common controls stuff you're using. It would be helpful if you would add in the following before the inclusion of <commctrl.h>:

#ifdef __GNUC__
#define _WIN32_IE WINVER
#endif

Could you please also move all the declarations from within for()s to the outside? I've tried everything I can, and there's no way I can get MinGW to compile those files.

With the above changes, it successfully compiles in MinGW! (What put me off it before was the "undeclared" errors that resulted from the macro definition problems I outlined at the top of this post.)

You might want to check the "Debug" profile, too; many TCHAR related errors are produced.

 

[rabiddeity]

OK, Poobah... the first one I'd add in, except that if someone compiles for a lower version of Windows, then the internationalization won't run properly under 2000 or later. I don't like having people compile separate versions of the .dll for 9x/NT kernels. Better to add a WINVER define to the Makefile, and tell everyone they have to have the latest libraries. Maybe I should add a pragma error if WINVER is less than 0x0500. That might be helpful.

I added the _WIN32_IE define to settings.h and moved a few #define lines; it should get defined before commctrl.h gets read in.

Ok, I don't think you going to not make your tenative release date, especially with this new BUG!!!

When you switch paks in a game, the rumble never works. I'll give you a scenio.

Start Beetle Racing, go to options, plugin in mempak, select right mempak file, click use, shortcut key to "unplug" then switch to "mempak", let game load save, later when prompted, shortcut key to switch to 'rumpak". No rumble in game.

The whole time the messages are popping up (only using Jabo in windowed) and everything looks as if it's working, but it's not. This of course was not the case in earlier releases. Good Luck!!:arabia:

Oy, you guys are too good. Back to the coding board...

Oh, one more thing. If you have bugs that show up when you click Use, see if they show up when you click Save. I know PJ64 tends to just reinit plugins when it feels like it (for one, when you load a savestate) and in that case your settings will get lost because the plugin reloads them from the registry.

I need to document these things better. Any takers on the manual, or should I write it?

 

[Poobah]

Have you updated the source with the new changes? (Thanks for implementing them.)

I didn't see any response to:

Could you please also move all the declarations from within for()s to the outside? I've tried everything I can, and there's no way I can get MinGW to compile those files.

Will you do this?

I can't write a manual for you, but I can proof-read the one that is written for you.

 

[rabiddeity]

Have you updated the source with the new changes? (Thanks for implementing them.)

I didn't see any response to: ... Will you do this?

I can't write a manual for you, but I can proof-read the one that is written for you.

ack... is it still breaking for loops, even with everything renamed to .c and compiled with c99?. Man, I don't understand why that would still be breaking stuff in gcc, as it's listed as part of C99 spec:
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
(scroll down to Syntax, point number 15)
At the worst, it should give you warnings and still compile. I'll download MinGW when I get the chance, and try compiling it myself.

The current manual isn't really that helpful. I wanted something that explains what ALL the buttons do, and some of the functionality is a bit different between 1.83 and 2.00 (like the rumble pak stuff, for example). I guess since I know the source better than most people now, I'll just write it myself; it shouldn't take TOO long.

edit: Source updated. Haven't tried compiling with the new changes but I don't think it breaks anything. Caveat compiler. Or something.

 

[Kumoashi]

Any plains on adding voice pak support?

 

[Agozer]

Any plains on adding voice pak support?

This has bene asked before, and the answer was no.

 

[rabiddeity]

Legend: I need a debug log to get any further with this. Send me one where your rumble works OK, and one where you've switched back and forth and it doesn't work.

 

[Legend]

Here.

Opened Beetle, did rumble stuff, then quit.

Then I ran through the steps I mentioned in my last post and got no rumble then closed rom. I then repeated that to make sure I did it right (turned message boxes on).

Also, I don't think it has anything to do with PJ64 not working right when you "USE" instead of "SAVE" settings. 1. It would default to my default of having rumble pak inserted and 2. it works fine on previous N-Rages.=]

 

[Poobah]

ack... is it still breaking for loops, even with everything renamed to .c and compiled with c99?. Man, I don't understand why that would still be breaking stuff in gcc, as it's listed as part of C99 spec:
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
(scroll down to Syntax, point number 15)
At the worst, it should give you warnings and still compile. I'll download MinGW when I get the chance, and try compiling it myself.

Sorry about that misunderstanding. It isn't possible to compile the troublesome source files as C, because the included headers are in C++, and it would be much easier to quickly move the 'i' declarations outside of the for() loops then to make the troublesome files C-compatible.

The current manual isn't really that helpful. I wanted something that explains what ALL the buttons do, and some of the functionality is a bit different between 1.83 and 2.00 (like the rumble pak stuff, for example). I guess since I know the source better than most people now, I'll just write it myself; it shouldn't take TOO long.

What I was saying was that I could proof-read the one that will be written -- not the current one.

 

[rabiddeity]

Legend:

I just went through the log and weeded out all the extraneous debug info to get an "abridged" version of your log. To me it looks like everything is working fine. I see some mempak writes, then a mempak unplug, after which the writes are flushed back... make sure you're not unplugging the mempak in the middle of an operation. The next shortcut keypress plugs the mempak back in (mempak/rumble switch plugs in a mempak unless there's one already there, in which case it switches to rumble). There are some writes, the pak is flushed, and then it finishes in plenty of time. I see a shortcut mem/rumble switch, which plugs in the rumble pak. After that I see a series of Rumble: DIES_NODOWNLOAD OK which means a rumble command was sent to a controller successfully. I assume this is controller 1 responding that it's rumbling OK, but apparently it's not.

It's more likely that this is rumble being sent to your controller 2. Can you check this? See if your controller 2 vibrates when controller 1 should be. After that, try setting your controller 2 to "unplugged" and see if it's a valid workaround. My debug logs from the current version unfortunately don't tell me which controller the mempak commands are being sent to (a bit of an oversight I know).

If nothing else, maybe I'm being distracted by rumble commands from another controller.... argh.

Before you post another log, let me add some more stuff to the debug logger. I'll post another NRage_Debug.zip with the debug DLL soon.

 

[Legend]

I did as asked and controller2 was not rumbling and when "unplugged" did not help the situation. And I always try to switch paks when prompted.

If you want another test game, f-zero is pretty quick. This is not a proper way of switching paks but a effective test. Use 1.83, go in game, feel some rumble, switch to mempak, then switch back to rumble, it won't rumble. But go to pause menu, hit retry level, and rumble's back like it should be. If you do this with 2.00, it never rumbles again no matter what; have to restart the game.

 

[rabiddeity]

I did as asked and controller2 was not rumbling and when "unplugged" did not help the situation. And I always try to switch paks when prompted.

If you want another test game, f-zero is pretty quick. This is not a proper way of switching paks but a effective test. Use 1.83, go in game, feel some rumble, switch to mempak, then switch back to rumble, it won't rumble. But go to pause menu, hit retry level, and rumble's back like it should be. If you do this with 2.00, it never rumbles again no matter what; have to restart the game.

There are two or three places where this could be going wrong, and I don't want to muck around with things until I have enough info to go off of. I'll do the F-Zero test and see what happens.

Legend: Plugin wasn't reinitializing DI effects properly. Bonehead move on my part. It should have crashed the emulator, but it didn't... hmm. Try it now.

Poobah: Sorry about the delay, but your source is ready.

 

[Poobah]

Poobah: Sorry about the delay, but your source is ready.

Thanks.

The release build now compiles perfectly when you move the WINVER declaration to take place before windows.h is included:
-In International.h, move the "#ifndef WINVER" block of code to before the "#include <windows.h>".
-In International.cpp, move the "#include "International.h"" to before the "#include <windows.h>".

I forgot to mention the errors that only took place in the debug builds; you haven't been using TCHAR for your debug strings and messages, so the compiler complains:

DirectInput.cpp:1114: error: invalid conversion from `const char*' to `CHAR*'
DirectInput.cpp:1174: error: invalid conversion from `const char*' to `CHAR*'
DirectInput.cpp:1204: error: invalid conversion from `const char*' to `CHAR*'

I'm not sure why the errors are occuring, but if you don't bother declaring a char* variable then you can just directly pass the strings to DebugWriteA instead.

 

[rabiddeity]

The release build now compiles perfectly when you move the WINVER declaration to take place before windows.h is included:
-In International.h, move the "#ifndef WINVER" block of code to before the "#include <windows.h>".
-In International.cpp, move the "#include "International.h"" to before the "#include <windows.h>".

Err... that's exactly what I was trying to AVOID. windows.h is where that's supposed to be defined, and if I put the define before windows.h it'll compile vs the 2000 libraries all the time. I don't want that-- what if we add a feature later? Add a -D WINVER=0x0500 in your gcc commandline options-- put it in the Makefile. I'm gonna remove that #define WINVER hack.

I forgot to mention the errors that only took place in the debug builds; you haven't been using TCHAR for your debug strings and messages, so the compiler complains:

DirectInput.cpp:1114: error: invalid conversion from `const char*' to `CHAR*'
DirectInput.cpp:1174: error: invalid conversion from `const char*' to `CHAR*'
DirectInput.cpp:1204: error: invalid conversion from `const char*' to `CHAR*'

I'm not sure why the errors are occuring, but if you don't bother declaring a char* variable then you can just directly pass the strings to DebugWriteA instead.

Yeah, if I use TCHARs in the debug output, it outputs the debug text file in UTF-16 format without a BOM (byte order mark). In other words, it'd be a file that won't open up in Textpad. So I write everything in ASCII instead, as all the debug stuff is in English anyway.

Looks like another preprocessor headache... the error is happening because gcc doesn't see "const LPSTR" as "const CHAR *". In Debug.cpp, change the _DebugWriteA( const LPSTR szFormat, ...) to _DebugWriteA( LPCSTR szFormat, ... )
If LPCSTR isn't defined for some reason, stick this line somewhere:
typedef CONST CHAR *LPCSTR;
That's a standard Windows typedef.

Does it compile yet? :borg:

 

[Poobah]

Err... that's exactly what I was trying to AVOID. windows.h is where that's supposed to be defined, and if I put the define before windows.h it'll compile vs the 2000 libraries all the time. I don't want that-- what if we add a feature later? Add a -D WINVER=0x0500 in your gcc commandline options-- put it in the Makefile. I'm gonna remove that #define WINVER hack.

Well, alright. Why you want it to be done this way does not make any sense to me, though.

Those three errors were with the lines that looked like:

	LPSTR suc = (SUCCEEDED(hr)) ? "OK" : "FAILED";

But your suggestion did work; changing the above to:

	LPCSTR suc = (SUCCEEDED(hr)) ? "OK" : "FAILED";

fixed it up.

A suggestion: to save youself and users the hassle of writing and searching through lengthy documentation, I think you should just use tooltips; it's much more convenient to move the mouse over a control to work out what it does rather than becoming frustrated and impatient while searching through the manual. Tooltips are great!

Oh, and now that I think about it, _WIN32_IE only needs to be defined as 0x300 because none of the more recent features are used by this plug-in; you wouldn't want to compile unneeded code into it! You should define this unconditionally, because space shouldn't be unnecessarily wasted. This change saves about 150KB in the debug build.

EDIT: What did you mean when you said: "and if I put the define before windows.h it'll compile vs the 2000 libraries all the time"?

 

[Legend]

Sorry, but the newest version (Sep 08) still doesn't work at all-it's the same. Are you sure it should work? Does it work for you? I just tried it with Beetle and F-Zero and it never reinitializes. Just to make sure, I went and tried 1.83 after and it worked perfectly.

 

[rabiddeity]

Legend: To be honest, I haven't yet tried. That patch fixed a major issue that I could see. Run it again in debug mode, with a working rumble and a non-working rumble as before. Maybe as a workaround, see if the problem still happens if you use the shortcut keys for unplug pak and plug rumblepak. I'm pretty sure I know what the issue is; it has to do with returning a "pak uninitialized" message when paks are switched, until the console sends "get status". In the case of the real N64, you usually remove one pak before plugging in another, so for a certain amount of time the console can see there's no longer a pak plugged in. Obviously if the console thinks the mempak is still plugged in, it won't check for a rumble pak.

The "getstatus" message returns whether or not a controller is plugged in, as well as a flag that says whether a pak is plugged in or not. This flag doesn't say what TYPE of pak is plugged; if it needs to use a certain pak, the ROM will run a sequence of test reads/writes to determine what kind of pak is inserted. Different paks behave differently when you query them. But this query sequence takes a lot of time, so it's not used unless it's known the pak has been changed. I think a newly inserted pak sends an error code unless it's been initialized, just in case someone with lightspeed hands changed paks without the console realizing. I gotta find those documents again....

Poobah: Usually redefining stuff that's defined in base headers tends to screw things up in the long run, often in ways that are hard to see. It might work perfectly now, but when MS releases a new platform SDK it might screw up the whole build. Since the WINVER problems are isolated to MinGW right now, we need to find a way to define it only when compiling with MinGW. I think it's a safer bet to include it in the Makefile. Either that, or I can try to put in an #ifdef that checks for a _MINGW macro or something. I know the compiler defines something like that by default. Yes, that sounds like a better idea. That way you won't have to put it in the Makefile.

I like the idea of tooltips. There is the issue of translation though.... For now I'm gonna write a manual because it's frankly easier to write, and I need some base material, but yes, definitely tooltips.

 

[squall_leonhart]

hey rabiddiety, can't you code in a 4-5second halt state between pak changes?

 

[Poobah]

Poobah: Usually redefining stuff that's defined in base headers tends to screw things up in the long run, often in ways that are hard to see. It might work perfectly now, but when MS releases a new platform SDK it might screw up the whole build. Since the WINVER problems are isolated to MinGW right now, we need to find a way to define it only when compiling with MinGW. I think it's a safer bet to include it in the Makefile. Either that, or I can try to put in an #ifdef that checks for a _MINGW macro or something. I know the compiler defines something like that by default. Yes, that sounds like a better idea. That way you won't have to put it in the Makefile.

Could you provide an example of how redefining WINVER could cause a problem? (The macros for checking MinGW are either __GNUC__ or __MINGW32__ by the way.)

I think the reason that the MS and MinGW headers work a lot differently is because Microsoft's documentation is sometimes inaccurate and it often conflicts with their actual implementations.