NRage Input Plugin V2.00 BETA (an overhaul)

[p_025]

One thing that's been bugging me, you have to mash an axis or rotation to 100% before it'll use it for a button push (GameCube Adaptoid, C-stick to c-buttons). This gets really annoying when you want to push more than one c-button at a time.

Another thing, I tested it, it does recognize different gamepads as being seperate. But it doesn't differentiate between them in the config dialog, it only says "Gamepad: Action X", so you don't know which one you've told it to use! Furthermore, if you bind some things to one gamepad, and other things to another, you've got a real disaster on your hands.

 

[rabiddeity]

hi,

i installed it and it works with debug mode, thank you

One question : What is so special with the debug mode?

Have i be careful about something?

Sorry for bad English

No problem, that's something I should make more clear on the front page. DEBUG is simply the most recent build of the plugin. RELEASE will get updated again as soon as I think I have all the bugs ironed out. The original idea was that RELEASE would be bug-free, but as you can see that hasn't been true.

 

[rabiddeity]

One thing that's been bugging me, you have to mash an axis or rotation to 100% before it'll use it for a button push (GameCube Adaptoid, C-stick to c-buttons). This gets really annoying when you want to push more than one c-button at a time.

It's currently set to 90%, because when experimenting with previous versions of the plugin it felt too easy to accidentally press two buttons at once (like in Zelda, hitting C-right to use an item sometimes resulted in me hitting C-up to go into first person, very jarring indeed). Right now, that number is hardcoded into the plugin, but I've been wanting to add it as a settable value for a long time. Now that the INI code is finally done, I think I can do that.

Another thing, I tested it, it does recognize different gamepads as being seperate. But it doesn't differentiate between them in the config dialog, it only says "Gamepad: Action X", so you don't know which one you've told it to use! Furthermore, if you bind some things to one gamepad, and other things to another, you've got a real disaster on your hands.

The only way to fix that would be to have something like the name of the Gamepad, but that's an arbitrary length string that often doesn't contain any useful information either. Unlike gamepads on a real console, I don't get a list of the controllers in any useful order or even in a consistent order. If you plug in an extra controller it will probably mess up the ordering next time you open the plugin. So if we used numbers then we'd have people asking why "Gamepad 1: Action X" sometimes says "Gamepad 3: Action X" even though they haven't re-bound it. Internally we use GUIDs which are unique but not really suitable for human consumption. Can you think of a better way to do it?

 

[squall_leonhart]

and what about the ability to read roms in zip files?

 

[p_025]

and what about the ability to read roms in zip files?

I'm sure you mean for the Transfer Pak. But old GameBoy and Gameboy Color roms weren't very large. Still, it would be handy.

As for differentiating between gamepads, I realize that there's no consistency. Maybe you could make an option for that in the ini file, disabled by default. I'm thinking something is better than nothing, here.

I'll make a post somewhere in the PJ64 forum, telling how it seems PJ64 isn't properly killing emulation. You can tell it to stop, but the internal name of the rom stays in the title bar and thigs like that...

 

[squall_leonhart]

thats actually how its supposed to work. according to zilmar.

 

[rabiddeity]

Sounds more like things aren't cleaned up as they should be. Ideally, you have a state machine where the state is exactly the same whenever you're at the ROM selection screen, whether you've just closed a ROM or just opened the emulator. Otherwise you can have strange errors where a bug only manifests itself when you run emulation, stop it, and then run emulation again. Makes things really hard to test, and as such it's bad design.

 

[p_025]

Sort of a follow-up to my mashing axes comment, maybe you could add the ability to specify an "outer deadzone," so you could press the axis to only 80 percent and the plugin reads as 100 percent, or however that works. This would also be very handy for the GameCube controller, since the analog sticks are octagonal.

Also, would it be at all possible to automatically lock the mouse when going to fullscreen? It would really help those of us with multimonitor systems, since the mouse likes to wander onto the second monitor. Or does the emulator not tell the controller plugin enough for that either?

 

[rabiddeity]

Sort of a follow-up to my mashing axes comment, maybe you could add the ability to specify an "outer deadzone," so you could press the axis to only 80 percent and the plugin reads as 100 percent, or however that works. This would also be very handy for the GameCube controller, since the analog sticks are octagonal.

Also, would it be at all possible to automatically lock the mouse when going to fullscreen? It would really help those of us with multimonitor systems, since the mouse likes to wander onto the second monitor. Or does the emulator not tell the controller plugin enough for that either?

Try unchecking "real N64 range" and see if that helps. I really don't want to have to muck around with adding more settings if I can get away with it. Also, make sure the joystick is calibrated properly in Windows, at least in the 4 cardinal directions.

I don't get information on whether the emu is in fullscreen or windowed mode. As you suggested, only the video plugin sees that.

 

[p_025]

Try unchecking "real N64 range" and see if that helps. I really don't want to have to muck around with adding more settings if I can get away with it. Also, make sure the joystick is calibrated properly in Windows, at least in the 4 cardinal directions.

Well, I guess I should have tried unchecking that box before. It certainly seems to help. Incidentally, what is the "Real" N64 range in percentages?

As to calibration, the GameCube adaptoid actually does not allow it, it really isn't necessary anyway. USB controllers are usually pretty good that way. You push an axis to 100% and it shows as 100%. The problem is GameCube controllers are octagonal, rather than quadrilateral. It's impossible to push two axes to 100% at the same time.

 

[rabiddeity]

"Real N64 Range" simply translates a square range of motion into the circular range of motion generated by a real N64 controller. So for those with a square physical range of motion, or a device that returns a square range of motion for a physical circular range of motion, this fixes it. For a concrete example, try pushing your control stick down and right while looking at the Windows controller test page. If the cross mark is positioned in the absolute bottom right corner of the square, you should turn Real N64 Range on. If the mark doesn't go all the way, but pushing just to the right makes the mark move to the right edge, then you should turn Real N64 Range off. If you can't get the mark to touch the four edges at all, you need to recalibrate your joystick.

 

[p_025]

"Real N64 Range" simply translates a square range of motion into the circular range of motion generated by a real N64 controller.

Wow. If I may say so, that's absolutely brilliant. If I'd known that's what that thing did, I would have unchecked it immediately, since GCN controllers have that same circular stick setup...

EDIT: I created a thread on the PJ64 forum explaining the bugs we've been having. http://www.emutalk.net/showthread.php?t=41778

EDIT2: LOL it got moved.

 

[rabiddeity]

Good luck. Officially those issues we've been having are "features" and not "bugs".

 

[squall_leonhart]

hmm, the buttons on the shortcuts panel don't seem to fit the entire names of gamepad buttons

maybe changing it to say joypad instead of gamepad?

 

[p_025]

Good luck. Officially those issues we've been having are "features" and not "bugs".

It's a "feature" that the input plugin is not informed of anything that's going on?

Anyway, I'm sure we can figure something out. Maybe there's some variable you can look for to see whether it's in fullscreen or not, and same with whether emulation is active or not.

 

[Legend]

Speaking of shortcuts...I thought maybe you can look again at the "Show messages" button and how it's display got broken. It would be really nice to see the text boxes in Fullscreen but at the very least, perhaps have them work again properly in Windowed. :*

 

[squall_leonhart]

they work ok for me in windowed,.. but not in fullscreen in 1.7

BUT, there is hope!, it is very possible that with the nrage 2.1 plugin can make use of the PJ64 1.7 status display feature but you might have to enquire about how to do it with jabo......

 

[Legend]

You're probably using Jabo's plugin which uses DirectX. Messages still show I think with DX. But the problem was with opengl (Rice's and Glide64) not showing the messages in windowed.

 

[squall_leonhart]

use Mudlords Rice Video, the status messages show in OGL windowed...

 

[Legend]

Well, I see a transparant white outlined box on with Glide64 instead of the message (windowed). There was a whole discussion somewhere in this thread about it and it was aknowledged but I don't think anything has changed since then.