Force Feedback Using SteamOS Xpad Driver?
#31
(10-26-2015, 11:27 AM)kust2708 Wrote: Do you feel a different intensity when you drag the intensity slider ? Normally, the gamepad must rumble proportionally to the slider value.

No it is always the same intensity, but don't worry about it, it's problably caused by the controllers driver they are very generic and the controller is a piece of crap Sad i wanna buy a steam controller to see how that does

Thanks for your work
Reply

Sponsored links

#32
(10-26-2015, 11:49 AM)tiagoplacido Wrote: No it is always the same intensity, but don't worry about it, it's problably caused by the controllers driver they are very generic and the controller is a piece of crap Sad i wanna buy a steam controller to see how that does

Thanks for your work

Thanks for your feedback. I wanna buy a steam controller too. Tongue
Reply
#33
(10-25-2015, 10:55 PM)shoegazer Wrote: So I tried with the null spu2-x plugin... and that worked, no more crashes.  The new plugin looks quite nice, a HUGE improvement!  A few comments:

1) Try to incorporate "left joystick config", "right joystick config" and especially "gamepad configuration" on the main menu so it doesn't require opening an entirely separate window.  IMHO, all options should be one click away, on the main menu.

2) Consider adding a "Set all buttons" option, which configures all buttons at once, with some visual indicator as to which one the UI is currently focused on.

3) The option "Use mouse for left analogic joy" should be "Use mouse for left analog joystick".  ;-)

Otherwise, very nice!  I'm wondering if you could work your magic on other areas too (especially the main UI, which imho badly needs a serious overhaul).  It will be really great to have a Qt-based UI rather than wx (with some of your work hopefully surviving the transition), but this is quite good in the meantime...

1) Incorporate options on the main frame will be difficult. One potential solution is to increase the width of the frame, but for the moment I prefer to improve features. For instance, actually the rumble intensity and joystick sensibility is common for all gamepads.

2) I added the "Set all buttons" option. But there are still some bugs with buttons label which disappear during the setting process.

3) Done.

Concerning the Qt version ... It's a lot of work, may be later.
I hope this time you will not have the core dump of the last time.


Attached Files
.zip   libonepad-1.1.0.so.zip (Size: 902,21 KB / Downloads: 171)
Reply
#34
(10-27-2015, 03:18 PM)kust2708 Wrote: Concerning the Qt version ... It's a lot of work, may be later.
I hope this time you will not have the core dump of the last time.

Don't listen to them. They will kill you, PCSX2 users are typical french guy, never happy Wink

Wx is fine. And maybe wx will get a qt backend one day.
Reply
#35
(10-27-2015, 04:22 PM)gregory Wrote: Don't listen to them. They will kill you, PCSX2 users are typical french guy, never happy Wink

Wx is fine. And maybe wx will get a qt backend one day.

Shhhhhh I try to motivate him to do it too.
Well, it is clearly not the number 1 priority but Qt is just so much more nice, it would hereby remove SDL version bugs and avoid compiler version crap. But it runs still, so it's fine I guess, and evdev will fix SDL problem soon enough. I guess next step is to make SPU2-X link on libpulse directly(through portaudio is possible too maybe?).
Reply
#36
Well I'm not against QT. But it tooks a lots of time to have a nice GUI. IMHO there are preliminary step before thinking about a qt (or whatever hype) toolkit. For example, repace wxString by std::string or a nice wrapper. But it is really low-priority. First priority is to stabilize the current change so I can make this release.

pulseaudio will be really nice but I'm afraid of the complexity. It will be even better to have a correct pulseaudio support in portaudio.
Reply
#37
(10-27-2015, 07:31 PM)gregory Wrote: Well I'm not against QT. But it tooks a lots of time to have a nice GUI. IMHO there are preliminary step before thinking about a qt (or whatever hype) toolkit. For example, repace wxString by std::string or a nice wrapper. But it is really low-priority. First priority is to stabilize the current change so I can make this release.

pulseaudio will be really nice but I'm afraid of the complexity. It will be even better to have a correct pulseaudio support in portaudio.

Yep, there are other priorities than Qt, that I know, don't worry. It's clearly not for this release anyway(and probably neither for the one after considering time it would take), as you say. Wrapping wxString would definitely be a good idea still. Having API dependent code paths is never so good.

I don't know how hard it will get yes. I will study that after too, important part is to use libpulse instead of direct pulseaudio, that one I understood, as this avoid shutting down the sound of every other applications... Which is not nice at all. Plus libpulse can be used with ALSA plugins behind and thus will not break stuff for users who use that by mistake. Most important is to not have any hard dep to pulseaudio as it will cause problems for many users. If I jump on that I do plan to do it with portaudio, might as well factorize stuff.
Reply
#38
(10-27-2015, 08:49 PM)3kinox Wrote: Yep, there are other priorities than Qt, that I know, don't worry. It's clearly not for this release anyway(and probably neither for the one after considering time it would take), as you say. Wrapping wxString would definitely be a good idea still. Having API dependent code paths is never so good.

I don't know how hard it will get yes. I will study that after too, important part is to use libpulse instead of direct pulseaudio, that one I understood, as this avoid shutting down the sound of every other applications... Which is not nice at all. Plus libpulse can be used with ALSA plugins behind and thus will not break stuff for users who use that by mistake. Most important is to not have any hard dep to pulseaudio as it will cause problems for many users. If I jump on that I do plan to do it with portaudio, might as well factorize stuff.

Well I think Portaudio doesn't like pulseaudio (because it is PA too Tongue2) You know free world and politics. Maybe they've change their minds.
Reply
#39
(10-27-2015, 09:21 PM)gregory Wrote: Well I think Portaudio doesn't like pulseaudio (because it is PA too Tongue2) You know free world and politics. Maybe they've change their minds.

haha well, I don't like pulseaudio either, but for quite technical reasons... Well poettering is anything but diplomatic too... When you try to shove something in someone's throat, even if it is in theory good, they will spit it back on you, Systemd is quite the example. In case of pulseaudio, I already exposed my reasons not to like it in other thread(gosh, that attenuation makes my ears bleed).
Reply
#40
(10-27-2015, 04:22 PM)gregory Wrote: Don't listen to them. They will kill you, PCSX2 users are typical french guy, never happy Wink

Wx is fine. And maybe wx will get a qt backend one day.

Haha... shocked that you think I'm a typical ungrateful PCSX2 user!  Smile

Seriously, just throwing all suggestions on the table since opinions were solicited.  Qt is certainly one of them, but as I said I'm certainly happy with the current wx stuff for now (and especially after Kust's nice rework).  As I believe we discussed before, there are far higher priorities than a graphic overhaul anyway.  Wink

3kinox: totally agreed on your thoughts regarding pulseaudio.  I've been testing gregory's latest SPU2-X PR which adds an option to set the SDL driver to alsa - and while it works nicely, you have to set it every time you launch PCSX2 for some reason we haven't yet figured out (it's set to alsa in the GUI on launch, but won't actually use alsa until you revert to pulseaudio and back to alsa in the GUI).  Oddly enough, if you set "export SDL_AUDIODRIVER=alsa" in console before launching, it starts with alsa just fine, regardless of how the GUI is set.
Reply




Users browsing this thread: 1 Guest(s)