NRage Input Plugin V2.00 BETA (an overhaul)

[Legend]

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

I don't like that because it will slow the process down even more. That would be frustrating and people would not know what's going on. We've lost message boxes and I don't want to lose the instantaneous transfer as well. I don't like regression, I was hoping we could make the process easier, not slower and with no message boxes saying what's going on.

If older versions can do it, then so too can the improved version. I'm off to work and I'll do some debuging when I'm off.

 

[squall_leonhart]

message boxes are fine for me... i they have always worked in windows mode for the Dx plugin, and i can sometimes get it to work in the fullscreen mode as well.

 

[Legend]

Well there is unequivocal proof that there IS some regression with the message boxes. Jabo's was the only plugin that I've found that was uneffected. Even Rice's, using the DirectX engine, still had some issues as my notes earlier showed.

Message Boxes are not a big deal (although it can cause some instability) but when combined with other regressions then that's not too good.

Here's the debug of rumble, rom close, mempak changing, no rumble, etc...
Not using shortcut keys make no difference. Still not being reintialized.

Good luck and keep up the hard work Rabiddeity!!!

 

[rabiddeity]

OK, I've fixed up an issue where FF devices could slip through without getting reacquired, but the more serious problem with swapping out paks is still there. I need one of the following:

1. Some serious documentation about N64 controller paks and/or controller interfaces, specifically initialization procedures, and how paks behave when they haven't been specifically initialized yet (do they return an error code? where? what kind?) I need information about handling raw PIF ram values, not mempak formats or any of that. The closest thing I have is a "dx!hwdox.zip" file that has some very basic information on how to read controller buttons and axes. Most of that doc is good, but some of it is just plain wrong. And it has absolutely nothing on reading or writing controller paks. Stephen Hans had some great info (http://home.t-online.de/home/stephan.hans/n64.htm), and then his site got taken down. Does anyone have an archived copy of it?

2. An adaptoid so that I can figure it out myself. This is what I really need to do it RIGHT, as I don't know how far I can trust any documentation I find on the net. The company that made them stopped making them awhile ago, but if someone here has one I can use it to figure out how the controller pak is SUPPOSED to behave.

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.

I can't give you an example because MS hasn't released Vista yet. :evil: Seriously though, since the implementations are different I'd just rather not redefine something that MS defines. I put in the #ifdef in the International.h file. Tell me if it doesn't work.

I also changed around a couple const TCHAR * to LPCTSTR and things like that, so I might have broken the delicate balance that is the cross-compile, heh. It's just for consistency. I'm also trying to add const qualifiers in function headers where possible, to make things easier to debug and make the code easier to follow. But it's a slow process and it's not completely done yet.

Keep me up to date on the MinGW issues.

 

[Legend]

I can't help you with any of that. Your Aug. 17th version worked fine, you can't compare what's happened since then? Do you have a debug version of that and if so, would it help for me to do a side by side comparion with that one and current version?

 

[rabiddeity]

I can't help you with any of that. Your Aug. 17th version worked fine, you can't compare what's happened since then? Do you have a debug version of that and if so, would it help for me to do a side by side comparion with that one and current version?

errrrr.....

damn, I don't keep daily source changelogs. And a lot of stuff has changed since Aug 17th build. Do you know when it stopped working?

Download the latest build and see if it fixes it. From the most recent debug log, after you opened up the config dialog and closed it, the controller was trying to rumble but failing because of a DirectX problem, which I just fixed.

 

[Legend]

God, I wish!! But no, this Sep 12th build does not work as well. Arghh....That's the only other version I got...Don't give up....

 

[rabiddeity]

Alright, I reverted the major ReadController changes and one major ReadControllerPak change. Download the latest DEBUG version and run it (I haven't changed the "release" version). Timestamp is 12 Sep 2006, 1:31PM. If that doesn't fix it, I'll undo the reverts and release one more version that might fix it.

 

[Legend]

I'm sorry man. Still not working. Here's the debug proof if you want it.

 

[Poobah]

I can't give you an example because MS hasn't released Vista yet. :evil: Seriously though, since the implementations are different I'd just rather not redefine something that MS defines. I put in the #ifdef in the International.h file. Tell me if it doesn't work.

I also changed around a couple const TCHAR * to LPCTSTR and things like that, so I might have broken the delicate balance that is the cross-compile, heh. It's just for consistency. I'm also trying to add const qualifiers in function headers where possible, to make things easier to debug and make the code easier to follow. But it's a slow process and it's not completely done yet.

Keep me up to date on the MinGW issues.

You forgot to include "International.h" before <windows.h> in International.cpp. There's no use having WINVER defined after the Windows headers are already included!

LPCBYTE isn't defined in the MinGW Windows headers, for some reason, so you should define it in the __GNUC__ section of settings.h.

The plug-in is only using features available in IE versions 0x300 and below, so _WIN32_IE would be more appropriately defined as just this.

The above two changes could be applied by changing:

#ifdef __GNUC__
#define _WIN32_IE WINVER
#endif

to

#ifdef __GNUC__
#define _WIN32_IE 0x300
#define LPCBYTE unsigned char *
#endif

GCC doesn't support "#pragma message", by the way, so you might aswell not put those there for the MinGW-specific preprocessor things.

 

[rabiddeity]

Poobah: Got it. Check the latest source. I moved the __GNUC__ stuff to the settings.h file, and put settings.h at the top of commonIncludes.h. Is there a way to send compile-time messages through GCC other than #pragma message?

I've commented out the datatype.h file include in "NRage PluginV2.h" so let me know if that causes any problems. Who knows why that was in there.


Legend: Is there any reason you're hitting the "unplug pak" toggle before hitting the "switch to mempak" toggle? If you do that, it will just plug the mempak back in without switching to rumble. When I give the workaround of "unplug the pak and then plug in the rumble pak" I mean use the "Insert Rumble Pak" shortcut, not the Mem---Rumble shortcut.

Once you finally do switch to the rumble pak, I'm seeing plenty of DI_OK messages from the calls to start rumble effects. Meaning as far as DirectInput is concerned, your device is rumbling. I don't have timestamps so I don't know when this is, or how long it takes for the pak to get redetected as a rumble pak after you switch. I assume your test rumble works OK.

Here's the debug log with all the crap cut out. The hex numbers you see are mempak reads and writes. Shortcut 0 0 means pak unplug on controller zero (N64 controller 1), Shortcut 0 6 means mem---rumble shortcut pressed. The stuff about "pak wasn't initialized" is a warning that the pak was switched before a getstatus was sent, meaning that the pak is still trying to write data to a pak which may have been changed out (in this case it's because the paks' initialized state is invalidated when you enter the config menu, I think). In the reverted version, this will report no error back to the ROM.

Notice how you don't get any rumbles until the second time the 0 6 shortcut is pressed, when it switches to rumble. That's because a rumble pak isn't plugged in until that point.

 

[Poobah]

In settings.h, BYTE hasn't been defined at the point where LPCBYTE is type defined, because windows.h hasn't been included at this point. Of course, windows.h shouldn't be included at this point because WINVER must be defined prior to its inclusion. The #define method solves this problem.

MinGW produces warnings about WINVER being redefined. This isn't bad, because it is still being defined before windows.h is included in International.cpp, and so it is compiling correctly. You should do one of the following:
-Make sure #include "commonIncludes.h" is before #include <windows.h> in all the source files.
-Use an #ifndef WINVER conditional statement so that it is only defined when needed (when you have included it before windows.h, which is the case for International.cpp, which is the only file that needs WINVER to be 0x500.)
-Take the WINVER definition out of settings.h and only use it in International.cpp.
-Remove the WINVER and _WIN32_IE definitions, and I can put them in the makefile, although MSVC builds won't benefit from the slightly reduced size.

Did you just comment out the inclusion of datatype.h in NRage PluginV2.h? It won't compile now, because UINT16 and INT16 are defined in that file. That file shouldn't be being used anyway, though; that's what stdint.h is for, and I'm sure it is more accurate.

Regarding making the preprocessor output text, I don't think GCC has this functionality. You can, however, use #warning or #error to produce warnings or errors, respectively. If, for example, you included:

#warning WINVER redefined

then the compiler would output:

settings.h:35:2: warning: #warning WINVER redefined

Outputting these messages wouldn't help all that much though, because most users wouldn't see them because of all the other warnings being produced!

For some reason, windres -- the resource script compiler that is part of the MinGW package -- doesn't work at all with file names that contain space characters. Could you replace the space in "NRage PluginV2.rc" with an underscore?

 

[Legend]

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!

 

[rabiddeity]

Alrighty. Well, I'm on vacation in the USA visiting my family until the 19th... but these changes are going right on the burner when I get back.

Poobah: In order... I can typedef BYTE as well in the __GNUC__ area. It shouldn't break anything. I'll do options 1 and 2 for the WINVER defs; the first because I should, and the second because it's a good idea. Which files use UINT16 and INT16? I can include stdint.h, in the __GNUC__ area to solve that. windres uses batch files, which is why it doesn't like filenames with spaces; I'll remove the space to fix that. Easy fix.

Legend: Did you steal my cat?
OK, so let me see if I understand this: the problem only manifests itself when you go into the config menu while the rom is opened... this explains a little bit. If you hit Use or Save when a rumble pak is selected, it works OK? One more question: if you just open the config panel while the ROM is running and hit Save without changing anything, does it screw up? I think I need to make sure the config menu invalidates the pak if the pak gets changed. Just so you know, I'm only doing these changes on the debug version, not release for now. This is so that if I break something, it won't affect the release version. So don't worry about the release version not working for now; when it gets fixed in debug I'll merge it to release.

 

[Legend]

That's what's going on in the debug version, if you go to the config while the rom is running, THEN paks won't get reinitialized EVEN if you change NOTHING and hit "use" or "save".

 

[Poobah]

Which files use UINT16 and INT16? I can include stdint.h, in the __GNUC__ area to solve that.

The only file that uses those is "NRage PluginV2.h". If you uncomment #include "datatype.h" on line 29, then the problem will be solved, or you could choose to only include datatype.h for MSVC, and use stdint.h for MinGW, type defining int16_t to INT16 and uint16_t to UINT16.

 

[rabiddeity]

The only file that uses those is "NRage PluginV2.h". If you uncomment #include "datatype.h" on line 29, then the problem will be solved, or you could choose to only include datatype.h for MSVC, and use stdint.h for MinGW, type defining int16_t to INT16 and uint16_t to UINT16.

Thing is, MSVC doesn't need that datatype.h file in order to compile. That's why I commented it out, and why I'm trying to figure out where the INT16 and UINT16 refs come from. Can you give me line numbers?

 

[Poobah]

Doesn't MSVC have any search functionality? In NRage PluginV2.h:
-UINT16: Lines 318-319.
-INT16: Lines 308-309.

 

[rabiddeity]

I'm not at my computer right now, that's the only reason. I'm off on vacation. It'll be quicker when I finally do get back.

Hmm... looks like another one of those GCC header differences. I'll see if I can remove the refs when I get back. Most likely it can be replaced with short and unsigned short.

 

[Poobah]

Rabiddeity, I have two suggestions:
-The whole form refreshes whenever I input something for one of the N64 buttons. Do you think you could change it so it doesn't do this?
-A "define all buttons" mode would be very useful. This could be a button on the form, and when clicked, it could go through each N64 button/axis and allow the user to input them all without having to click each button individually.