Comments (15)
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.
from 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,
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.
from project64.
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.
from project64.
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?
from project64.
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.
from project64.
@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.
from 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
from project64.
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.
from project64.
"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.
from project64.
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.
from project64.
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.
from 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.
from project64.
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.
from project64.
The UI translation system Nrage is using could do with a good replacement
from 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
from project64.
Related Issues (20)
- [Bug]: Downloads page on pj64-emu.com website not working HOT 2
- [Feature request]: Increase the maximum number of Cheats able to be turned on. HOT 1
- plugins glide64 add 3dfx option HOT 4
- V-Rally Edition 99 issues HOT 7
- Cannot join Discord channels HOT 3
- [Bug]: Banjo Tooie freezes at intro screen with wrong camera angle HOT 2
- [Bug]: I Cant Disable My Fast Run Cheat In B3313
- Save state cannot be loaded HOT 12
- [Bug]: Stuttering with all the plugins HOT 16
- [Bug]: Blues Brothers 2000 can't get past the alligator in Sewer in Chicago HOT 6
- [Bug]: various game not reaching the title screen. HOT 9
- [Issue]: Save files are locked even after ending emulation
- [Bug]: Xbox 360 controller doesn't respond when playing HOT 1
- [Feature request]: OpenXR support / VR HOT 2
- my project 64 has this problem CN64System::EmulationStarting:exception caught file n64system/n64system.cpp line:680 how do I solve this problem in the emulator HOT 1
- [Bug]: Black screen on every game; no video and audio HOT 9
- [Feature request]: Interactive Table of Contents HOT 1
- [Bug]: Banjo Tooie crashes after taking off wireless earbuds HOT 2
- [Bug]: DK64 Camera Crashes the Game HOT 1
- Terminate PID 8568 HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from project64.