I've been following this issue for a while, hoping some sort of motion plus support would be merged to master. So, what is the situation? The devs don't want to duplicate effort because it's already been started, but can't pull the branch due to extraneous changes? Annoying users demanding support didn't help, I'm sure. Did anyone try to cherry-pick the motion plus revisions or are those too intermixed with the extra stuff? Maybe I'll take a look at picking apart the change set later (no guarantees, though). I'd like to see basic motion plus support in the input plugin so udpwii could support it. I think there's enough sensors in higher end phones for that.
Steel01
Apparently the Motion Plus code from JPeterson doesn't follow the coding style used in Dolphin, and now it'll be a little harder to merge, the patch is old and merging with the latest build will probably have a lot of merge conflicts...
@Shomuni
I know, i just joking around. Yeah i see. Just benefit last build with WiiM+ emulated
@Major
Oh, nice to know. I think JPet had what he wants, and not interest to get more
But i thought work on is feature might used by dolphin user (because you have rarely a controller can't contain all key without keyboard+Mice but hard to play) is just useless
@Steel01
Yeah i had same idea about phones ! but i'm not a programer
@Jhonn
I see, thanks for all answer but we all know that it's lost cause
[color=#8920A3][/color]
Merging this may not be as difficult as I first thought. Then again, it might end up worse... I started with the official dolphin master and branched it. Then I added jpetersons github repo as another remote and merged it to my new branch. After a few minutes of pruning, I think there will only be six or seven conflicted files. I don't have the tools available to easily check the conflicts, but I don't expect they'll be insurmountable. I'll check that out tonight. The problem I see popping up is the relevant files referencing changes in files that should be irrelevant.
Another thing, a comment in the gyro issue on the github mirror states that the changes haven't been merged back because someone hadn't signed off on allowing it. Dolphin is GPL, yes? So by license, any changes made to a derivative can be pulled back upstream with no additional permission.
Steel01
P.S. I would have used URL links for a couple things above, but mobile Firefox doesn't seem to want to let me paste anything in a textbox atm.
Edit: I thought some of the M+ stuff was in his master branch, but the more diffs I look at, the more I think that's not so. I'm going to have to try and compile that master and input branch and tinker with them. So, much of the above may become irrelevant.
Steel01 Wrote:Another thing, a comment in the gyro issue on the github mirror states that the changes haven't been merged back because someone hadn't signed off on allowing it. Dolphin is GPL, yes? So by license, any changes made to a derivative can be pulled back upstream with no additional permission.
Uh, no. Open source is run by the people committing to it and working on it at the time, and the master branch IS the project. If 10 people say no and one person says yes, the answer is no. Period. If he tries to force it they'll just revert it and remove his committing rights (which happened to jpeterson because he kept doing exactly that, twice).
However, since it is open source, there's nothing stopping him from working on it as a branch or fork. It just won't be merged back into master. Disagreements like that are why there are so many different versions of Linux.
Steel01 Wrote:The devs don't want to duplicate effort because it's already been started, but can't pull the branch due to extraneous changes?
None of the devs will work on it because they don't care. Even if the code was magnificent, emulated motionplus will never work well. Think about it. The wiimote with the motionplus has six axis of motion (lateral plus rotation) and a pointer (2D space so two axis), plus the nunchuk has 3 axis of motion (lateral only) and 2 axis on the joystick. That's 13 axis dude. How many does a gamepad have? Two joysticks: 4 axis. Playing a a motionplus game on a gamepad is not pretty. So the devs are satisfied with just requiring the motionplus for motionplus games, and leaving it at that. If someone was to make a decent version of emulated motionplus with clean code and a lack of dumb unrelated changes, I think the devs would consider it though, even if it's only to make this jpeterson build stuff go away.
Umm... That's not the direction I was referring to. I wasn't suggesting forcing anything into the official tree. The comment I was referring to said one of the committers to petersons tree hadn't given permission to move it up to official. From what I know of the GPL, since the code was based on the official tree and committed to a forked project, the official devs could pull the changes into official if they wished without express written permission from that codes dev.
And yes, I realize the limitations to using a gamepad or mouse to emulate the motion plus. But it could be made to be sufficient for some games. Like was reported in this very thread, someone finished Skyward Sword on petersons code. Plus if someone did udpwii support, a phone accelerometer could handle all axises.
I'm working on cleaning up the code from petersons input branch. I've cleared out a lot of extraneous stuff and am trying to get it to compile. As expected, my first pass is spitting all kinds of errors. If I can get that to work, I'll try to get the code up to standards. I presume there is a coding standards page on the googlecode wiki?
Steel01
(10-23-2013, 06:21 AM)MaJoR Wrote: [ -> ]However, since it is open source, there's nothing stopping him from working on it as a branch or fork. It just won't be merged back into master. Disagreements like that are why there are so many different versions of Linux.
I don't like that comparison, in particular the "disagreements like that" part. People have different ideas on how to design an operating system, which is why there are different products using the same underlying kernel. That's a LOT different from a fork. And then there's also different reasons for forking projects; in this case, one developer actively did everything to stand out negatively and to not conform to the projects guidelines. Just to give you a small insight, while we're currently using issue tracking + git repository on github, he decided to setup his own repository and tracker on github. He wouldn't ever respond to questions asked on IRC, but instead replied on a github issue without notifying the one who asked the question. It was ridiculous. Need I say more?
(10-23-2013, 06:21 AM)MaJoR Wrote: [ -> ]None of the devs will work on it because they don't care. Even if the code was magnificent, emulated motionplus will never work well.
It would actually really be nice to have working motionplus emulation, for debugging purposes. I do have a wiimote with motionplus extension and a bluetooth setup which works fine with that wiimote, yet it's always a mess to use. I don't want to fiddle around 15 minutes when I just want to quickly go ingame in red steel 2 to check some stuff for 2 minutes. Yet, accepting 3rd party code under these circumstances is unacceptable. I guess any attempt to clean up JP's patches is doomed to fail anyway, so the only realistic chance of emulated m+ support in Dolphin is if someone actually wrote everything from scratch.
(10-23-2013, 06:39 AM)Steel01 Wrote: [ -> ]I'm working on cleaning up the code from petersons input branch. I've cleared out a lot of extraneous stuff and am trying to get it to compile. As expected, my first pass is spitting all kinds of errors. If I can get that to work, I'll try to get the code up to standards. I presume there is a coding standards page on the googlecode wiki?
I'm not sure if that's the only thing you're currently doing, but getting the branch merged against master and cleaning up the coding style mistakes are the least problems we have with the branch right now. It's basically one heap of unreviewable mess with lots of other crap intertwined. Heck, I never understood why he added that RawInput stuff on top of everything in the first place.
Anyway, if you actually want to tackle these issues - make sure you're looking at the correct and up to date branch. I think
https://github.com/mirror/dolphin-emu/pull/3 is what you want (not sure though, because none of his recent PRs mention "emulation motionplus" directly..).
So, third party code won't be accepted? Is that due to a policy or because it's based off code from a guy that ticked off the rest of the dev team? Not saying that's bad or trying to argue with the project lead, I just like to know solid reasons. Either way, I'll probably still try to make it work for personal use, but I won't post about it if you don't want to see it.
I'd consider starting from scratch if I had the second clue about emulation programming. I kinda have the first clue just by hanging around them since the 90's. But I have no programming experience in relation to what would be needed.
Steel01
Edit: And now this post is mostly irrelevant and I can't delete it. Okay Neo, I'll take a look there. Thanks.
Edit 2: I removed most files from the merge and planned to try to do minor tweaks to what is left to make it work with as little changes to master as possible. I think I'm at 10-12 changed files atm. But that doesn't compile, so who knows where it will end up.
I said "accepting 3rd party code under these circumstances is unacceptable". I think my post was pretty clear on why that is so in this particular case. We're of course open to any 3rd party code if there's any reasonable way to review it and we agree with the change.
Wow... Pardon me while I stare in disbelief at that pull request. I lost count of the different issues there. Okay, so if I can get that down to just m+ and gyro changes (related enough?), is that acceptable? Code originally submitted upstream, refactored by someone else and resubmitted? Though, this is all contingent on me actually getting it to compile. Still working on that and may be for some time.
Steel01