(10-10-2015, 02:03 PM)3kinox Wrote: Your wish is (partially) done. Now, help me to run tests
clone this one: https://github.com/3kinox/pcsx2.git then checkout the branch rumble_onepad (all other branches are very outdated other stuff. You need to compile with sdl2 enabled.
I will probably remove possibility to use sdl1 with this. I will keep legacy code somewhere just. sdl1 seems broken at least for dualshock3 anyway.
Rumble is always on, no way to deactivate it yet(I'm on it, but I cppfy the code at the same time, will be done soon, before monday night).
My next commits will break ini conf too. But anyway most options were not even taken into account.
Can you test it on multiple games that use rumble? Tell me how it goes, tell me how near to ps2 it feels too, for DMC3 it is quite near, I used it as my reference until now. I only have dualshock 3 and 4 to test too. Could you test on non dualshock pad?
Interface will more than probably get a refresh soonish too. My appartment-mate(is it how it is said? I am french sorry) is working on it.
For sensibility, it is already possible to change it directly in ini as I understand. But I am not sure of the effect, and I have no games which have problems with it to test anyway...
I also have no Windows and I don't know how rumble goes for Lilypad, are there any games which have problems there? Are problems on plugin side or core?
Wow, what a great surprise entirely out of the blue - thank you!
Question though, is there any way to compile JUST the onepad plugin? If not, then can you post a binary somewhere? Being x86 code, the entire pcsx2 project itself won't compile under my Ubuntu-derivative x64 setup (I'm not even sure the x86 plugin will compile by itself but I'm hopeful).
Once I have the means to test, I'm happy to do that for you of course. I have xb360 and ds4 pads here along with the original ds2, though I'll try to focus on the xb360 pad since you already have a ds4. I'll focus on how close it feels to my real ps2/ds2 setup. No idea about Lilypad but perhaps others can chime in here to help.
It's also a nice bonus that you're deprecating SDL1. Actually I believe the intent is to eventually move away from SDL entirely and towards evdev, using libevdev, as Gregory suggested here, but this is a great next step regardless. And thanks to your apartment-mate/flat-mate for helping with the UI!
10-11-2015, 11:35 AM (This post was last modified: 10-11-2015, 11:59 AM by 3kinox.)
OK, here is the plugin compiled so that you may test
It can not(yet?) be built alone. Anyway, it would still require to be built in i686 as it would be hard to link it against core otherwise.I will look into what I can do for that tonight.
As for evdev. Well, for now I am clearly re-engineering the plugin. The end design I see does include possibility to have multiple API. I am not entirely for dropping SDL2 though. SDL has the main advantage to be a well known cross platform API. It is however used a bit strangely in this plugin(why the f**k does it initialize absolutely every bits of SDL when it only uses a subset of its core plugin abilities). I also have a few "bugs" with it. But I think it is due to design flaws, not SDL. Once the re design is complete, evdev back end should be simple enough however.
For now, after I make all the "quick fixes", I will make a first PR.
After that I will concentrate mainly on isolating, understanding fully, and replace all the scary stuff(and there is quite a bit of it).
I will merge a good part of the classes into a mother class "device" which will then open the possibility yo instantiate to either "Joystick"(the SDL1/2 form) or whatever else you would like. That will be the point where evdev could be added. I will probably make SDL1 into its own class too, ready to be removed.
Building without SDL2 will then be quite doable. If spu2-x also builds without SDL, it would then be entirely possible to make SDL an optional dependency. However, SDL2, compared to SDL1 which is way too old to be used and hope for it to function fully as expected, is quite a good option I guess. It should be able to work both on Linux, BSD and MacOS too if the rest of the project would be made fully cross platform.
While I have nothing against a few OS specific backends, designing a piece of software around only one OS, architecture or set of APIs is flawed by design and will only lead you to problems. One day this OS may be upgraded and break backward compatibility or dropped altogether. It goes the same for architectures and APIs.
It is the work of the designer to make sure the software survive this change. And this entails remaining as platform agnostic as can be.
Furthermore, when building against only one target, many bugs will tend to be neglected. They will just be mitigated until program "just work". This is a big problem because this kind of bugs will resurface one day or another and will be insanely hard to debug since the rest of the stack was built on top of them.
All this to say, let us not repeat mistakes of the past which were done in other plugins, let's be as cross platform as can be, let's integrate as well as possible with the project, let's focus on making code as elegant as can be and try to build a design that is future proof.
So, okay for an evdev back end, it could be quite a nice addition, but the plugin must not be designed around it, neither should it be around SDL.
Merci beaucoup! I'll test later on today and let you know what I find. No worries spending a lot of time getting it to build independently - if it finds its way into a PR/main codebase I assume it'll eventually be in Gregory's PPA. I wish the entire project would compile, but the PPA is the next best thing I guess.
In any event, I really like your ideas and thoughts on "future-proofing" pcsx2 - in fact I believe ALL software projects should be handled like that, especially emulation projects that seek to preserve computing platforms for future generations (and therefore in my opinion answer to a higher calling). That said, I think pcsx2's x86 codebase does more to threaten it's future than SDL or anything else really, and who knows if that will ever change.
Anyway, as you may know Dolphin switched entirely away from SDL for specific reasons that make sense. In theory SDL should be a better option, and the only input API necessary across all OS'es - cross-platform should always be the preferred route - but given its limitations I can understand their position and I think the project is better for it. For that matter I also believe plugins in general should be simply integrated into the main codebase as Dolphin has done, which would ease maintenance across multiple platforms, ease troubleshooting, and other benefits - but that hasn't happened so far of course. I'm not a programmer but the reasons I've read about this design approach do make sense.
10-11-2015, 06:10 PM (This post was last modified: 10-11-2015, 06:13 PM by 3kinox.)
Ok thanks, for input
I did not read dolphin explanation actually. I see the point. Well, having an evdev back end does make sense even more. I also have some bugs with sdl2, including some weird one with closing joystick which was there before me. So I kinda see the point. I shall try to see for evdev then. I don't know how to use it, but I can probably understand it from doc and dolphin code example(houray for free software ).
Indeed, x86_32 is probably much more of a problem haha. Fixing it is daunting, actually, after trying to port it before, I would say it can not be just "fixed". The only real fix is to go through the interpreter, clean it up, make sure it is just as compatible as the rest, make it able to use the debugger, and then use it from there as a base to make a frontend to a full fledged DBT/JIT. It is definitely doable but it requires motivated people who have deep understanding of each parts of the design. However, it would pay off a lot. Once you go this way, you get a fully retargetable DBT which means you can support virtually any host(and even target!) at minimum costs(about 1K line of code per host). If it is well done, perf will be quite near to non retargetable ones. Problem will arise if it is not done very well however...
For plugins well, that's one type of design. It definitely has its pro... But quite a few cons. The main flaw with it is that it violates one of the main principles of Software Engineering, code reuse(each plugins will re implement same stuff). The main advantage is that it manages relatively well to isolate code and allows to share between different emulators. In the end, it all depends on your use case, if no other emulator shares with you, then it is clearly disavantgeous, on the other hand, if a lot does, then it is mainly beneficial(code reuse is then done across multiple emulators instead of one).
Also, I completely forgot, but could you test to see if "sixaxis plugged in usb" hack does anything for you? It seems to not do anything for me. Actually work perfect without it.
10-11-2015, 07:51 PM (This post was last modified: 10-11-2015, 09:18 PM by 3kinox.)
OK, unsolvable SDL bug found... I try to fix it but now way to do it clean... It is discussed here http://forums.libsdl.org/viewtopic.php?t...sc&start=0 so it's not pcsx2 related. I "fixed" it by not closing joystick. It does the trick for now. It's kind of a memory leak but anyway, it's very small and probably not possible to notice... It's not even a real "leak" as a matter of fact, since it is reused and does not seem to hit stability. it is already that way in build I gave you. If you don't have crash or strange behavious let's consider all is okay for now.
Maybe evdev is a freaking good idea though
EDIT:
I pretty much cornered every "bugs". There is some strange stuff still but no show stopper, I need to get better understanding of the overall design before I can tackle it. So I will test new build/commits, then upload to get your next tests, and then PR.
After I shall concentrate on understanding and updating the design, making it mostly agnostic, see if this strange things can be solved then, and finally create an evdev backend.
10-11-2015, 10:37 PM (This post was last modified: 10-11-2015, 11:09 PM by shoegazer.)
Ah yes, I believe that's the same SDL issue I observed in Dolphin before they switched to evdev - specifically, that Dolphin crashed constantly especially when opening the controller dialog. Actually I had solved it myself by moving from SDL2.0.3 to SDL2.0.4, so perhaps it has already been fixed (?) although from that thread you provided, I can't tell what version they are using. I have not run into any SDL-related crashing problems with pcsx2 - though again it could be that I'm 2.0.4 and don't see it.
By the way, I spoke with phire (the Dolphin dev who drove the evdev/libevdev port) and he's graciously offered to provide any tips on porting to evdev if you need it - he won't code anything for you, but will offer info. on what he knows. Hope it helps.
Totally see your point about x86, and completely agree on all the benefits it would bring. We'll see what the future brings - I have no idea what state the x64 work is in (someone was working on an emitter a while ago?) but with any hope it will eventually get done. Agreed that it takes a lot of work, time, willingness and talent. I also see your point on plugins, though I do agree that the advantages of a plugin-free architecture outweigh the disavantages. And, I've never used a plugin designed for one emulator with any other, and devs of any new ps2 emulators would likely write a new input subsystem from scratch anyway.
Speaking of plugins, on to yours - it works WELL, thank you! Rumble seems to be about accurate to my ps2 in almost every game I tried (about 10), I had to run side-by-side to be sure because I couldn't remember - but that's with my ds4 pad. It works with my XB360 pad too, but the rumble is a SLIGHT bit weaker than my ds4 or my real ps2/ds2. Not a big deal really, but worth mentioning. One game, Gran Turismo 3, seemed a bit off though, like the rumble is too strong or always on when it shouldn't be, but I'm not sure - I didn't get a chance to compare that one on my ps2 yet, so I could be misremembering. When going over a bump and getting "air" the rumble does turn off, so it isn't a bug or anything.
Anyway, feel free to post new binaries whenever you need more help testing - but wow, so much nice progress already!
Update: Forgot about your request for "sixaxis plugged in usb" - I also don't think it does anything, and seems to work fine without it. Also, with GT3 adding a second controller (controller 1 is ds4, controller 2 is xb360), the game seems to hang on the selection screen - but that might not be input related? Finally, with GT4, rumble only works with the first controller in a 2-player game, regardless of whether the first controller is the ds4 or xb360 pad.
10-11-2015, 11:15 PM (This post was last modified: 10-11-2015, 11:44 PM by 3kinox.)
My pleasure, happy that progress is appreciated, I will post new binary soon, make one last check before going to sleep just.
Indeed, I am using 2.0.3 so this could explain that. However, considering I use archlinux, it must be the case for pretty much everyone. I also have some strange stuff happening with rumble depending on where I call code, most likely related to design this one, not sure yet.
I did try a go at emmiter and all but the complexity of porting current code to x64 outweight that of coding a real code generator/Design an IR. And it would be at pure loss since "new" code would be tied down to x64... And porting to arm or ppc would be just as hard all over again.
For evdev will be pretty helpful already, I will look into the code directly too. And see code examples.
For xbox pad, as my memory goes, it had weaker motors. But I can try to look into it, I will add sooner or later a way to change intensity too.
Answer to update: For the second plugin problem, it might be related to me, can you test with vanilla version? Normally what I did should not have caused that, but sometimes side effect can be funny...
EDIT: OK, here is new build! You can now deactivate rumble, there are some protection against stupid crash dumps, and it seems quite stable to me. Time for me to go to sleep then
If all goes well with you, I will make PR tomorrow. Will continue to iron it out then, isolate sdl specific code path and get ready for evdev while making all more object oriented.
Ah yes, now that you mention it, I recall seeing your nick attributed to some of the x64 emitter work (thanks!). Hopefully your x64 contributions along with those of others will eventually come to something. As far as being "tied down to x64," wouldn't the fact that future arm/ppc procs will all be x64 nullify that concern in time?
Now on to test results... it seems your newest plugin also works very well, I saw no difference between the previous one (good or bad) after going back over the games tested yesterday, but I'm sure the stability fixes are there. Aside from the GT3/GT4 issues I mentioned yesterday, only one game, "Total Overdose" doesn't seem to exhibit any rumble, even though the game controls just fine. I do recall rumble working in Lilypad/Windows but that was quite a while ago when I last checked. I thought I had triggered events in the game to force rumble (e.g. blowing up an oil drum) but I could be wrong I suppose.
Hope it helps, but just let me know if you need anything else.
(10-12-2015, 09:48 PM)shoegazer Wrote: Ah yes, now that you mention it, I recall seeing your nick attributed to some of the x64 emitter work (thanks!). Hopefully your x64 contributions along with those of others will eventually come to something. As far as being "tied down to x64," wouldn't the fact that future arm/ppc procs will all be x64 nullify that concern in time?
Sadly, it is not as simple. x64 is just a shorter way to write x86_64 e.g. it is still fully specific to Intel cpus. PPC has gone the 64bits road a long time ago, with a lot of success but they have completely different architecture(e.g. no way to run an Intel x86_64 software on them). For PPC in reality, we don't really care as, at least for now, they hold far from any market that would interest us(pretty much only server and nintendo hardware).
For ARM, the problem is the same, they use their own architecture. They do have a 64bit architecture since not long ago, but it is also with their own set of instruction. It is absolutely not compatible with Intel. Same goes for MIPS btw. Though for mips, porting PCSX2 on it would obviously not be so harrible as... It is now an overset +/- some instructions of the PS2 main CPU. For ARM(and also a bit for MIPS) it can be seen as a limitation not to support them in any way as these devices are used quite a bit in mobile phone(MIPS is mostly limited to china though). However, the most critical for now would still be x86_64 as Linux distro are slowly but surely moving toward less and less support for 32bit x86, and pretty much everyone will then proceed to drop it more and more. Of course, it will not happen in the next few months, but in a couple of year it might be on us. Even Fedora and Ubuntu are finally making plan to drop 32bit. It is a thing of the past, and should be sent to rest.
(10-12-2015, 09:48 PM)shoegazer Wrote: Now on to test results... it seems your newest plugin also works very well, I saw no difference between the previous one (good or bad) after going back over the games tested yesterday, but I'm sure the stability fixes are there. Aside from the GT3/GT4 issues I mentioned yesterday, only one game, "Total Overdose" doesn't seem to exhibit any rumble, even though the game controls just fine. I do recall rumble working in Lilypad/Windows but that was quite a while ago when I last checked. I thought I had triggered events in the game to force rumble (e.g. blowing up an oil drum) but I could be wrong I suppose.
Hope it helps, but just let me know if you need anything else.
Cool, well, no difference is quite perfect it's pretty much what we want here.
Hmmm no rumble at all is probably linked to core then. Or the game doing something exotic with its rumble commands. Rumble is just triggered whenever the core send the command to for now, so if rumble is off timing, or off strength I might be guilty, but for none at all it seems more like core is in cause. I will try to dig.
On another note,I just finished(like 5 minutes ago) to isolate SDL specific code. It means evdev work can begin soon, I do need to understand a few things first but it should be good.
At least, all is isolated now
Also, my flat mate still work on interface, he finished drawing the images he wanted. He will then use wxwidget to make the new interface and I will integrate the code later on.
Ah yes, quite right of course. I meant to say 64-bit, not x64 - but then, your original comment was regarding x64 anyway, so nevermind. Suffice to say it would be great to see PCSX2 running on more (preferably 64-bit) platforms as Dolphin has been doing for a while, but that seems far off in the future, sadly. I too have seen distros moving quickly away from offering 32-bit variants as they used to, especially the popular ones - so yes, entirely agreed that some change in PCSX2 would be quite needed. Besides, I have to imagine there are performance gains to be had in 64-bit territory, no?
Anyway, we're way off topic... it may be that "Total Overdose" is doing exotic things with rumble, it makes perfect sense and explains the aberrant behavior. If your digging uncovers the source, I'm happy to test it again of course.
I saw your PR issued and then redacted but I understand the reasons and it seems the outcome will be even better for it. Looking forward to it, especially the evdev stuff.
Also looking forward to checking out your flat-mate's work - a fresh, new and modern UI would be quite cool! I assume you are referring not just to OnePad but PCSX2 in general? From what Gregory says any major changes may need to wait for a while, but that's fine of course.
