Replacing Jabo Direct Input with N-rage about project64

[project64]

It does store its settings in an .ini file which is good, I do not nessarly have to get it to go though the project64 settings system, but it should at least store then in the config folder. Same with the log in to the log folder

I make the logs and conf folder writer to by a non admin that way the files are not subject to redirection by the OS on vista+, where the root directory does not have this so the files will be stored in a redirected folder under the user account.

[cxd4]

It does store its settings in an .ini file which is good, I do not nessarly have to get it to go though the project64 settings system,

Oh my, yes that is a relief. And here I thought you were decisive on project64-izing N-Rage plugin, in the way that Glide64 was project64-ized (e.g. Glide64.ini becomes an RDB file). Different folder to move it under /Config ... eh...that's reasonable. It hardly breaks backward-compatibility with the original N-Rage plugin as long as the INI file wasn't even changed at all.

[cxd4]

All I ever do is game on my keyboard. I would not be any more comfortable with any other device.

So I'm not too qualified to opine on this topic. I know at least a couple people who prefer Jabo's DirectInput over N-Rage DirectInput, for some reason.

Ignoring some more...fundamental issues, what I don't like about N-Rage 2.3 as a DLL in itself is that it is twice the code to maintain as the original N-Rage plugin before squall was left alone to work on it. N-Rage 2.1 = all of N-Rage and rabiddeity overhaul DirectInput code. N-Rage 2.3 can double the amount of code we'd have to maintain, because it merges in XInput dependency within a single plugin. However, it could be reasoned that most people today, who have DirectX installed to support DirectInput8, probably could get N-Rage 2.3 (with its XInput dependencies) to initialize as well. Bear in mind though that this isn't necessarily true for everyone, and if the assumption breaks, there will be no valid controller plugins installed to Project64 which are usable...meaning no usable input plugins and no way to start emulation without making people figure out plugins and how to change them.

So I like to minimize dependencies not maximize them. Plugins are already dependencies in order to get Project64 to initialize, and there can be infinitely many plugins, so better to have 1 DirectInput, 1 XInput plugin, than to have 1 merged DLL which requires both to be installed.

[oddMLan]

In jabo's one I do like the picture of the controller and the setup button that goes through all the buttons in a row.

The GUI layout is basically the only thing I like more about Jabo's Input plugin over N-Rage.
Do you plan to make N-Rage's GUI more like Jabo's?

[LegendOfDragoon]

I personally prefer using Jabo's input, but it's not a big deal if it's not included. One thing about the newer NRage plugins is that with keyboard, the input for analog controls is different. Instead of instantly doing full range in a particular direction, it starts low and gradually goes higher in range (so it takes a few frames). I can understand why it's implemented, but it's not always good to be that way, imo anyway.

[cxd4]

@LegendOfDragoon is that not something controllable with the "Real N64 Range" checkbox option?

Figured I'd ask...guess I never noticed that myself. I'm usually too tolerant to "feel" those issues.

[project64]

The GUI layout is basically the only thing I like more about Jabo's Input plugin over N-Rage.
Do you plan to make N-Rage's GUI more like Jabo's?

yes that is one of the things I am considering

[LegendOfDragoon]

I tried a few options and none of them changed it ;/ . I tested 1.80a and 2.3b. 1.80a took 3 extra frames, 2.3b took 2 extra. It's understandable to implement that sort of functionality, but I generally prefer instant full range for keyboard input, rather than gradually.

[death-droid]

"that it is twice the code to maintain as the original N-Rage plugin"
Well thats false, the difference in code size between rabids last source release and the latest available is minimal.
Including the ability to use XInput controllers in NRage is a minimal code increase and is extremely easy to maintain.

I personally think the want to increase the amount of DLL's we use is just bizarre.

[cxd4]

Including the ability to use XInput controllers in NRage is a minimal code increase

Including XInput to go with a pre-existing API solution is never a "minimal code increase".
I think you know that. Stacking dependencies is never a matter of "minimal code increase".

Never said I want more DLL's. If you read in the other issue I said I suppose the fewer plugins that come with Project64, the better. Less plugins shipped with Project64, even NO plugins shipped with Project64 at all, would be a good thing to me. That's where you horribly misread my intention.

I only said that splitting redundancies like the mess that is N-Rage 2.3 would be a lesser evil, not that we need both a DirectInput and XInput plugin separately shipped. I never said 2 plugins is better than 1, just that 2 plugins is better than 1 horrific screw-together.

[marhry]

Something I did not see before and which would be a good thing for the official input plugin:

Optional key bindings for system commands.

Let me clarify: Many people use an Xbox360 or similar gamepad, which has more buttons than the N64 original. It is very convenient to put "Save state", "Load state" and others (e.g. "Fast forward") on these unused buttons.
So my suggestion is: Add maybe two or three boxes where you can just enter a key and which have a dropdown box that triggers one of the system commands. Or even simpler, just emulates a keypress.

[project64]

It is very convenient to put "Save state", "Load state" and others (e.g. "Fast forward") on these unused buttons.

Yes I would like to do that, at the moment it is not possible since I do not have the source of jabo's plugin, which is the point of looking at replacing it. It will not be in the first version, but probably in the version after that.

[marhry]

Sounds promising. The intermediate solution for me is to use something like XPadder to just fire the keyboard key that has been set in PJ64 on controller button presses. Might also be a starting point for the feature implementation, i.e. just let the input plugin fire VK_... codes on button presses.

[death-droid]

The UI translation system Nrage is using could do with a good replacement

[project64]

The UI translation system Nrage is using could do with a good replacement

What I did with the settings, it might be worth doing the same thing for language and do al the language strings though the main files, so that way you only have one location your editing. It does produce a higher coupling with the emulator but at this stage I think it is fine