..:: PCSX2 Forums ::..

Full Version: DS4 To XInput Wrapper
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(03-14-2014, 02:35 AM)InhexSTER Wrote: [ -> ]Considering how many issues araised with custom mappings i am not sure if we can create bug free profile system for 1.3, also changing to by mac address saving and so will require extensive rework of existing code. As well as introducing new elements in GUI to enable functionality. I'd rather do it once right than rewriting it for the next release. I also belive there should be fast custom mappings switching (as many as you want each in separate file in "mappings" folder). So this will allow re-use of mapping for 2 profiles. So all mappings will be available to every controller. Profiles will save all the data from the options, and again each profile in separate file in "profiles" folder. This approach will allow easy to copy/share individual profiles/mappings

Swtiching a profile will apply all settings of that profile (each profile can have its own color)
Switching a custom mapping will flash led once or twice with predefined color for that custom mapping.
Profile can save current mapping selected or have a default one.

This is sounding not that complex but if we would implement this it should be carefully though out first. As with custom mappings the way its implemented atm poses quite few limitations that can only be resovled rewriting the logic (specifically ability to bind multiple inputs to 1 input).

Anyways implementation of this all depends on what it should be, profiles per controller, profiles per game and so on. Imho we shouldn't rush this.

I don't even want to put in a real UI for it 1.3, just have a checkbox in the Options window for the setting "Auto-save/load profile" and have them provide a name for it. It would be only making it, effectively, so that you could quit and restart and not lose the current touchpad mode settings, and controller settings would be per-user. I don't think this is something that needs to go into 1.3.0 but I think saving the full controller mode state would be a good start. It's easy enough to continue forward and put more of this stuff in 1.3.1.

I don't want to wait for 2.0, to push features, though -- I want to prototype stuff in 1.x and use it to get a more elegant architecture in place for 2.0. We have a lot of effective freedom in development if we are fine with major evolutionary changes. I want to get the haptics engine stuff into 1.3 soon, and see how that appears to change the architecture. Same thing with if you decide to add rate selection for the sensor data. Same thing for audio output.
Well, first of all I don't really like how you keep changing your goals. Sometime ago we decided that 1.3 will be first common release and will be last one before 2.0. Now you are talking about 1.3.1
I also don't agree with the approach of posting updates of every day that just confuses forum users of all the versions out there. I release RC's only because the changes are so big they can break some features and make the tool not work on someone's machine. We shouldn't be posting new version everytime there is some new feature added. In extreme conditions where we find that version posted causes reproducible crash and effects good portion of people we should release fixed version ASAP .

I think architecture of DS4Library is good enough for 2.0. What needs to be done is changing DS4Control library to be able to handle new features.

And yes maybe I like to be a bit of a control freak but I believe the only way the project can evolve properly and not need a re-write every few weeks, we have to follow specific style/architecture/design pattern.
Since I've put so much work and dedication towards this project I think I should take on the role of team lead. Only if we have some specific roles and responsibilities defined and maybe at least 2 maybe 3 times a week meetings so everyone knows what others are doing. Otherwise I don't how we can keep the maintainability, stability and overall good quality of DS4Tool (I feel this is most important, not cool feature set). If you strongly disagree with me and really want it go different development path and would like to work on this separately than I would prefer if there was a separate thread for other versions of this.

I feel we just can't continue pulling it in different directions.
(03-14-2014, 03:51 AM)InhexSTER Wrote: [ -> ]I feel we just can't continue pulling it in different directions.

Hmm, I do see where you are coming from. At least from a 'more feature testing brings more troubleshooting and restructuring' mind set.

I think that was the general idea behind separate branches introducing things on the side lines that aren't an official release - it doesn't then jeopardise the main branch. Not sure if separate branches should constitute new threads though, as that discourages new development (and innovation comes best from diversity). Granted it can be time consuming when threads are updated so often.

I'm actually curious what the users on the forum think between many test versions with quick functionality introduction, or far less releases that are always succinct and robust.
(03-14-2014, 04:44 AM)HecticSeptic Wrote: [ -> ]I think that was the general idea behind separate branches introducing things on the side lines that aren't an official release - it doesn't then jeopardise the main branch. Not sure if separate branches should constitute new threads though, as that discourages new development (and innovation comes best from diversity). Granted it can be time consuming when threads are updated so often.

I am always up for new functionality and improvements to existing one i just want it be a specific set of planned features/fixes for each release so we have specific goals to meet for each release. I know its definitely more fun to take "I feel like its interesting or cool feature so I am going to work on it" approach. I believe features/fixes should be prioritized and marked planned for a specific version. So we can try to do ETA for each release, specific changelog. Keep to the same style and structure for future releases so the forks/clones of this can pick up changes easier.
I just don't like when work is disorganized, and there are no specific goals/plans.

Regarding the thread we starting to see a lot of overlap between each major release and dev versions discussed and a person maybe referring to any devs releases and each release can have its issues.

As i said before it might be good idea to get separate site with a forum, when each topic can be discussed in different thread. New features, dev versions, support and so on.

Each time the update is released it has good number of new features, and they thoroughly tested by each one of us, should increase overall quality and hopefully more people won't need to ask for support or file bugs.
I think each feature should be carefully planned out and working very well, I feel like if we are aiming to pick up many more features from other tools (like Xpadder) we should have functionality that at least on the same level as those tools. Otherwise what's the point of having features that don't work as well? People are going to use third party apps.
Imho we should either make sure the functionally is on par or better, or not have it at all, as people will be reverting to other solutions.
(03-14-2014, 05:05 AM)InhexSTER Wrote: [ -> ]I am always up for new functionality and improvements to existing one i just want it be a specific set of planned features/fixes for each release so we have specific goals to meet for each release. I know its definitely more fun to take "I feel like its interesting or cool feature so I am going to work on it" approach. I believe features/fixes should be prioritized and marked planned for a specific version. So we can try to do ETA for each release, specific changelog. Keep to the same style and structure for future releases so the forks/clones of this can pick up changes easier.
I just don't like when work is disorganized, and there are no specific goals/plans.

Regarding the thread we starting to see a lot of overlap between each major release and dev versions discussed and a person maybe referring to any devs releases and each release can have its issues.

As i said before it might be good idea to get separate site with a forum, when each topic can be discussed in different thread. New features, dev versions, support and so on.

Each time the update is released it has good number of new features, and they thoroughly tested by each one of us, should increase overall quality and hopefully more people won't need to ask for support or file bugs.
I think each feature should be carefully planned out and working very well, I feel like if we are aiming to pick up many more features from other tools (like Xpadder) we should have functionality that at least on the same level as those tools. Otherwise what's the point of having features that don't work as well? People are going to use third party apps.
Imho we should either make sure the functionally is on par or better, or not have it at all, as people will be reverting to other solutions.

No one has committed to sitting down and doing a 2.0 architecture other than that one enormous post I did detailing thread-level architecture which didn't really get feedback. This is why I didn't like seeing you just make a "dev" branch rather than a "1.3RC" branch. Take a look at how I am using git now. This is a feature branch. This is how git's distributed model is supposed to work. I honestly don't see 2.0 happening any time soon because I seem to be the only voice saying, "It's ok to throw out legacy code and just rewrite most of it."

https://code.google.com/p/ds4-tool/sourc...1.3haptics#
(03-14-2014, 03:51 AM)InhexSTER Wrote: [ -> ]I think architecture of DS4Library is good enough for 2.0. What needs to be done is changing DS4Control library to be able to handle new features.

I simply do not agree. From my decade of experience doing this sort of stuff (driver design (this is a driver, whether it is a user-mode driver or not, it's still a driver), API design for embedded software, low-latency multi-threaded software), I cannot actually say that I think this architecture is 2.0-worthy. There is no true recognition in the design of this software of as I/O-systems-as-feedback-networks. The input and output path are very flat and there is no real way to integrate the various parts. We REALLY ought to start over and define clear subsystems and architecture. We COULD simply refactor, refactor, refactor until we get there, but that way really hurts. It hurts stability and overall development time both. Iterative development or major rewrites are good. In the middle is bad, and that's what we've ended up doing now.
@Electrobrains

I am sorry, but I had enough of this, your last commit is just unacceptable, I asked nicely many times to not touch DS4Library, as it shouldn't have DS4Tool specific features (like haptic rumble). Many times i said we can add all features, new code paths inside DS4Control (thats is a where tool related code goes, not DS4Library and not HIDLibrary). Those, once there is almost no bugs, need to be untouched.

How can we possibly come up with strict architecture if you just will not ever follow it? I am just tired of restructuring your code every time because you just won't listen.
(03-14-2014, 05:54 AM)InhexSTER Wrote: [ -> ]@Electrobrains

I am sorry, but I had enough of this, your last commit is just unacceptable, I asked nicely many times to not touch DS4Library, as it shouldn't have DS4Tool specific features (like haptic rumble). Many times i said we can add all features, new code paths inside DS4Control (thats is a where tool related code goes, not DS4Library and not HIDLibrary). Those, once there is almost no bugs, need to be untouched.

How can we possibly come up with strict architecture if you just will not ever follow it?

First of all, I committed to MY OWN development branch, 1.3haptics. Second of all, I said I don't agree with your supposed subsystem breakdown/architecture, but you are not willing to listen to feedback on it. Finally, it is ludicrous that you think that haptic features are DS4Tool-specific and not something that people would use something like DS4Library for. The arbitrary split of libraries might be useful for your own organization, but it's not a good API design. Stop making knee-jerk reactions. If the Event crap is so brittle, chances are it's the wrong thing to use. How do you know it's actually low-latency/low-overhead? Why all these enormous abstractions instead of plain virtual method calls, where is the advantage? You're not even DOING any method call chaining with just a 1:1 correspondence between event sources and sinks.

Putting so much emphasis on DS4Library when there are zero consumers of it outside of DS4Tool itself is just tunnel-vision. I'm not going to develop software in a ridiculous way, because I've had enough of that from the for-profit software world. I am more than happy to just start over by myself if I think that my doing so is the only way the 2.0 I was hoping for would happen. We should be emphasizing REAL existing use-cases. Light bar visualization is so completely uninteresting compared to using motion controls.

I don't think you really thought about the DS4Tool-versus-DS4Library thing. So if I have special software that uses DS4Library... it has to communicate with DS4Tool to tell it to stop doing Xinput-y things and mouse-y things, right? How is that going to happen? Why not take that to the logical end and make it a network service and not a wrapper library that requires access to devices and, if a bug should occur, the wrapper library which does all the fancy hardware stuff will just crash the software the DS4Library is embedded in, but if it's just a simple network protocol wrapper, the worst-case scenario should just be disconnection, not a crash.

I'm glad you are excited about the directions you want to go but I think it's time to step back and look at the big picture, not a particular mental software development roadmap that spans into the distant future.
Sorry to jump in but I'd like to report an odd behavior I'm noticing on all versions of 1.3.

Sometimes I will have DS4 Tool minimized in the tray and be using my controller just fine. Then if I choose to alt tab out of a game, it opens DS4 Tool for a brief second as if it wasn't minimized, and when this happens it blinks on the screen then disappears from Windows altogether, but is still running in the background passing controller data to xinput. I cannot alt tab or open it via tray, it's just gone. But I see the process still running in Task Manager which I find odd.

Any ideas?
Uh, guys? 1.3 RC3 is working great, and you all seem to have been making pretty good progress collaborating so far, so it would be cool if you kept working together on it.

Sounds like there are a lot of fundamental architecture things you all need to agree on. Maybe there should be a written road map to 2.0?

EDIT: As for the multiple versions and confusion, I think it would be best to have a main release and label everything else beta or whatever. This tool is going to keep getting more popular and people are easily confused. There should be one clear version for people to download if they just want their controller to work as a 360 pad in games. Users that follow the development can then help test whatever versions are floating around.