What's new

NRage Input Plugin V2.00 BETA (an overhaul)

OP
R

rabiddeity

Plugin Hacker
Kruci has right, there are no big changes. Only Mupen64 crashs a little bit later... The strange "couldn't load language DLL, falling back to defaults" error message still appear in the debug file.

OK, the "falling back to defaults" message appears if you haven't selected the German plugin in the list of plugins and saved it. (Obviously if you delete the registry entry it will reset.) If it's not showing up at all, then we have a bigger issue.

BUT FOR NOW, please remove any NRage language plugin DLL files from your emulator folder! If there's a problem with the resource DLL files, it's possible that it will cause a problem with the plugin. I'm trying to simplify things as much as possible in order to narrow down the problem, and fix one issue at a time. So again, please MOVE or REMOVE the NRage-Language-XXXX.dll files from the emulator folder. Once the issue is fixed we'll move them back.

OK, sorry guys, you had the latest version of the plugin but for rather obscure reasons it showed the build date as being earlier.

Since I don't trust Unicode under Win9x, I've released a special build just for you guys, that doesn't use the UNICODE layer at all. This will rule out any problems in the Unicode layer. However, it won't load up language DLL files.

I've also updated the regular DEBUG binary again and fixed a rather glaring mistake in the Debug.cpp file which was causing a crash. Please try them both out. Since the files have different names, you'll have to select which plugin you want to use in the emulator (regular or ANSI).

ANSI version here
 

squall_leonhart

The Great Gunblade Wielder
HAHA, ok, This problem also exists on Windows ME

when i select the plugin in the settings window, project64 brings up an error, but its all in random characters :|

i'll test the latest dbug plugin.

putting in the unicows.dll from

http://download.microsoft.com/download/b/7/5/b75eace3-00e2-4aa0-9a6f-0b6882c71642/unicows.exe

fixed it...

those having issues,.. try copying unicows.dll into system32 oe system.. (whichever has the most dll files) instead of the pj64 folder.

also, make sure your unicows.dll is dated as of 2004... if its the 2002 file.. try thr newer version
 
Last edited:

Kruci

New member
both version seems to have same behavior
PJ64 - works, dont find any problems

1964 - works
(some problems with emulator(cant emulate blast corps corectly?))
 
Last edited:

lion10

New member
Both versions WORKS! No errors, no freezes and no hangs, on all 3 emulators! :bouncy:

It works also with the language DLL in the emu folder. The only bad thing is that I can run the plugin configuration only at the first time. After this, a click on "Input Settings" shows no reaction. However beside this it runs stable...
 

Kruci

New member
The only bad thing is that I can run the plugin configuration only at the first time. After this, a click on "Input Settings" shows no reaction. However beside this it runs stable...

I dont have this problem, me input setting always work.
 

lion10

New member
I dont have this problem, me input setting always work.


Interesting... Note, this issue only appears, if the language DLL is in the emu folder. So, if you put yours language DLL in the emu folder it really works normally?

If yes, it is probably an only German language DLL related error…
 

h2oz7v

New member
Just started using this plugin, but I'm having problems with the "C-Pad" buttons. I have a SuperJoy Box 13 (GC to USB) and the C buttons seem slow to react, even though its mapped correctly. On my Laptop, they dont work at all.
 
OP
R

rabiddeity

Plugin Hacker
Just started using this plugin, but I'm having problems with the "C-Pad" buttons. I have a SuperJoy Box 13 (GC to USB) and the C buttons seem slow to react, even though its mapped correctly. On my Laptop, they dont work at all.

C stick on a Gamecube controller is an analog control, so if you're mapping to buttons it has to exceed a certain "threshold" before the stick is registered as a button press. First, under the Control Panel, open up Game Controllers and click Properties (on your joystick). Make sure that when you move the joystick/C-stick/buttons that the onscreen indicators all move quickly. If you're moving the C-stick and the indicator doesn't go all the way to the edge, you need to calibrate your joystick.

I'm adding a threshold option in the next version, but for now that will have to do.
 
OP
R

rabiddeity

Plugin Hacker
So everyone says it works OK now, except for the one issue with the German language plugin? Guys, this is great news. If there are no objections, I'm going to release 2.00b and start working on the 2.1 release.

For 2.1, these are the things on the list to be added/changed: ini files instead of registry, reworked .cpf format to store in human readable format, custom threshold settings, fixed up Adaptoid support. Anything else?
 

squall_leonhart

The Great Gunblade Wielder
how about a redetect feature so that if you start the emulator before plugging in the control you don't need to exit and restart it to load up the control.
 

h2oz7v

New member
C stick on a Gamecube controller is an analog control, so if you're mapping to buttons it has to exceed a certain "threshold" before the stick is registered as a button press. First, under the Control Panel, open up Game Controllers and click Properties (on your joystick). Make sure that when you move the joystick/C-stick/buttons that the onscreen indicators all move quickly. If you're moving the C-stick and the indicator doesn't go all the way to the edge, you need to calibrate your joystick.

I'm adding a threshold option in the next version, but for now that will have to do.

Yeah, I thought it would be something like that. The driver for the GC USB converter doesnt actually have any way to calibrate, although it does show a response when a certain button is pressed.

For now I'm still using the old NRage plugin, but good luck with further releases!
 
OP
R

rabiddeity

Plugin Hacker
shortcuts and modifiers are still not saved, I dont find any other problem.

Dammit. OK, I re-released 2.00b. Sorry guys, I had added calls to specifically disable Shortcut and Modifier reading from registry, and then forgot to change it back. Should work OK now, go grab the RELEASE version again.

Trunk port from source isn't going to compile correctly right now because I've totally ripped everything apart, if anyone is following along.
 
Last edited:
OP
R

rabiddeity

Plugin Hacker
squall: Redetect feature, yes. That would be very useful, and I'll look into it. I think I can get DirectInput to send an event when a device is plugged in.

XInput, no. I'm not going to muck with the DInput code (and there is a LOT of it) just to fix a lack of support in Microsoft's driver, and despite what MS says, XInput has not replaced DirectInput, nor will it. This article explains it much better than I can; read the first and the fifth posts: http://channel9.msdn.com/ShowPost.aspx?PostID=246604

As a side note, I laughed when I saw this as a "feature" in the link you posted: "XInput devices (i.e. The Xbox 360 controllers) will have vibration functionality only when using XInput APIs". Wow. So MS's broken DInput driver for X360 controllers is a feature? Uhhh...

Sorry, I don't mean to troll on ya there. It's a good controller, but I honestly don't know what MS was thinking when they wrote the driver. Just use XBCD, it's better.
 

squall_leonhart

The Great Gunblade Wielder
no probs :p i prefer XBCD myself.. but at the moment its not useable on the Wireless XB360 control and Wirless xbox controls...

i use a modded xbox control myself.. but the xbox360 control looks cooler :p

mostly coz it has 4 buttons on the top (2 buttons 2 triggers) :p
 
OP
R

rabiddeity

Plugin Hacker
OK guys, just to let you know I'm still working on this thing. I made a HUGE commit to the source tree to kick off the 2.1 branch. I've ripped out all the registry calls and added in stubs for loading/saving from INI. Once I finalize the INI format, I'll start coding the save and load functions.

The resulting code is much cleaner and easier to read, and all the settings load in one function and save in one function. (Before, there were independent functions for loading general settings, buttons, modifiers, and shortcuts, which was confusing as hell and prone to error. Now all the settings are stored in one place so we either load all the settings at once or none of them.) This should make the DLL smaller too, when it finally comes out.

Finally, now is the time for all good MinGW users to come to the aid of their plugin. As much as I'd love to twink around with getting the plugin to compile correctly under compilers other than Visual Studio, right now I'm focusing my efforts on other things (see dev notes, second post of this thread) and I can't seem to find a concise guide on how to install and configure MinGW. Therefore, if you're enterprising and have some free time, I need TWO things from the MinGW community.

1. Write a Makefile that tries to compile a DLL from all the source available, given that the person compiling has the Win32 API and at least DirectX 8 API installed. A generic Makefile should do this anyway. I know at least one of you guys tried to compile with MinGW. Didn't you create a Makefile?

2. Fix any problems that keep the code from compiling or generate warnings when compiled with -Wall. You should download the latest source from "trunk" on my subversion server, and then proceed to hack away until you get it working. If you can at least iron out some of the kinks and think you can fix them all, I'll give you a branch of your own to work on, and then when you get it all working I'll merge the changes back into trunk.
 

Top