..:: PCSX2 Forums ::..

(02-01-2014, 10:28 PM)electrobrains Wrote: [ -> ]Oh I just realized how we should treat the LED by default: just blink the indication color periodically instead of having it "solid" on. Have the blinking increase in urgency as battery runs down!

Off first glance it looks like the flash is hardware controlled. Could it be set 0 for no flash and higher values indicating a speed?

Otherwise would have thought that'd require a timer of sorts, not sure if the timer present in the main UI still exists in 1.1, I haven't seen all changes yet code wise. I wouldn't feel comfortable adding another timer to do it - they seem overhead intensive. If the main UI can handle the timing it could just update the color between black and the previous colors?

(02-02-2014, 01:39 AM)DirtyShady Wrote: [ -> ]Ok, I'm ready. Tell me when you want I translate in french.


Do you think you'll add Color Panel GUI in next version to choose LED color ?

Example :

https://kuler.adobe.com/build2.0.0-build...el_730.png

Language translation it's already on my to do list, it will probably be a XML file in a specific folder: add another XML file correctly formatted and at the next reboot of the application you will see the new language available.

About the Color Panel: i don't know if you tried the beta GUI that i'm working on, but i keep the sliders because i find it more easy to select the correct color. Anyway i need to add a Textbox for entering manual value.

(02-01-2014, 10:53 PM)pedrovay2003 Wrote: [ -> ]The UI looks fantastic. I can't wait for it to be fully functional! I actually love the Metro look.

I assume you're going off of electrobrains's build? I noticed you had a settings in there for the LED to blink at 50% like electrobrains's version has, so that's what kind of tipped me off.

EDIT: Wait, they're being merged, aren't they? I already forgot about that.

Thanks
I'm not going off of any build ATM, as i said it's just UI behaviour testing, i only picked the last screen interface that i had available and it was an old electrobrain's build.
I will not start uploading code until there is a single GIT repo (i suppose it will happen with 1.3) and it will be officially usable with 2.0 (at least i hope so )

(02-01-2014, 11:23 PM)pol77 Wrote: [ -> ]Hello!

I registered to thank the developers for giving us this great tool!

As I see that you are developing the GUI, how about this icon? I can help with other graphics if you need something.

Thanks but i've already most of the GUI i need
And considering that the app is using a metro style, the icon should be a lot simpler. Thanks anyway

(02-01-2014, 06:13 PM)Pro_info Wrote: [ -> ]very good job and very good interface although I personally do not like the metro style.

Mmm maybe an option to disable the "Metro UI" and revert at a more classical and simpler interface?
Shouldn't be hard and it will need a restart of the application, but i'm not sure that every GUI functionality would be preserved, i need to try it.

(02-01-2014, 09:19 PM)electrobrains Wrote: [ -> ]Wow, this looks great. From discussions with InhexSTER yesterday, I want 2.0 to be a little bit more intricate: you have a number of different DS4 devices (electrobrain's DS4, Donbabbeo's DS4, InhexSTER's DS4) which each have some associated preferences: custom mapping (like the arthritis mode I just added), LED configuration, etc. Then you have up to 4 virtual DS4 Xinput devices with the other remaining half of the configuration.
We multiplex a number of DS4 devices into the individual virtual DS4 devices. So we need to configure preferences where virtual DS4's get associated with (certain axes of) real DS4's, and we should also allow for a DS4 being hooked up with both BT and USB simultaneously and "just handle it". The GUI would have to let you individually disconnect each end, BT and USB, if both are in use.

One use I have in mind of ganging multiple DS4 devices is using the motion controls in conjunction, using two DS4 controllers at once, one in each hand, and mapping that to thumb-stick axes, etc., of a single Xinput device. The more common case would just be motion controls from a single controller mapped to one Xinput device, but I'm pretty convinced on this direction of allowing fully arbitrary mapping of controls, including muxing and demuxing at different layers.

Additionally, the output side will have 1-4 Xinput devices, that we already know. But I will be adding support for REAL virtual input devices, rather than the synthetic events system that is very limiting. So we need one or more devices represented other than just the Xinput devices, that will act as keyboards/mice/touchpads/tablets.

USB/Bluetooth recognition it's already planned, it will be showed via an USB cord or/and a bluetooth symbol near the controller image.

I will think how to represent in a simple and elegant way all of those info, i probably represent the virtual input with miniatures of mouse/KB/touchpad etc in the right area of the controller, any suggestions for xinput virtual device?

I have in mind something like this:


(@Jays2Kings: i will probably need some more arts on the same style of the controller image )

I could translate it in italian if needed

Ah so the https://code.google.com/p/ds4-tool/ isn't effectively the repository you're all using?

I did some tweaks for my personal taste (needed to manually update to 1.1 by seeing the
diff of each file from beta 3 to 1.1) and set the following extras on it:

- Minimize on start
- A single start/stop button instead of both
(uses resources not literals - on that note why not use built in resources?)
- Low Battery colour
(instead of forcing Green/Red it takes your chosen 1st colour and the chosen
low battery colour, so if you select black (the default for this) 0% battery
means no light). That can be set where colour is usually set, but I added the
colour picker above each. You only see the low battery colour options if its enabled.
- Changed left click to clicking on the actual pad, and right click to the PS button
(which is irrelevant in most games).
I suppose it could be an option instead between the two,
but its just my personal preference.

Am keen to see this two finger detection on the touch pad I saw mentioned as well. Have attached my changes (can give code if anyone thinks it'll be useful, followed conventions and all .

Edit: (Image)

(02-02-2014, 05:48 PM)uugui Wrote: [ -> ]I could translate it in italian if needed

I'm sure it's not necessary, i'm italian too

(02-02-2014, 04:57 PM)Donbabbeo Wrote: [ -> ]I have in mind something like this:


(@Jays2Kings: i will probably need some more arts on the same style of the controller image )

Not a problem, I can PM some images when I finish, or I'll just edit this/make a new post.

(02-02-2014, 04:42 PM)HecticSeptic Wrote: [ -> ]Off first glance it looks like the flash is hardware controlled. Could it be set 0 for no flash and higher values indicating a speed?

Otherwise would have thought that'd require a timer of sorts, not sure if the timer present in the main UI still exists in 1.1, I haven't seen all changes yet code wise. I wouldn't feel comfortable adding another timer to do it - they seem overhead intensive. If the main UI can handle the timing it could just update the color between black and the previous colors?

Check out this branch, the one I've been working on mostly:
https://code.google.com/r/brianfundakows...ource/list

The flash rate is handled by the firmware on the DS4, at least for a certain range of speeds. Take a look at the behavior I have for starting to flash at 50% and flashing with increasing urgency at 40%, 30%, 20% and 10%. I feel that ultimately the simple way to configure battery-based LED and flashing behavior will be a table of ten states and an LED color and flash pattern definition for each: charging/100%, 90%, 80%, 70%, 60%, 50%, 40%, 30%, 20% and 10%. I also want to make rumble effects part of it. You simply define your haptic feedback cycle, whether it be LED or rumble or speaker or some combination. This is a 2.0 thing, though; for 1.3 I'd just allow configuring the flash rate and LED color per battery level.

(02-03-2014, 01:51 AM)electrobrains Wrote: [ -> ]Check out this branch, the one I've been working on mostly:
https://code.google.com/r/brianfundakows...ource/list

The flash rate is handled by the firmware on the DS4, at least for a certain range of speeds. Take a look at the behavior I have for starting to flash at 50% and flashing with increasing urgency at 40%, 30%, 20% and 10%. I feel that ultimately the simple way to configure battery-based LED and flashing behavior will be a table of ten states and an LED color and flash pattern definition for each: charging/100%, 90%, 80%, 70%, 60%, 50%, 40%, 30%, 20% and 10%. I also want to make rumble effects part of it. You simply define your haptic feedback cycle, whether it be LED or rumble or speaker or some combination. This is a 2.0 thing, though; for 1.3 I'd just allow configuring the flash rate and LED color per battery level.

From the code I'd say you might as well just calculate a value dynamically instead of have stages? Unless it impacts performance.

You could, for example, set it to 255 * battery / 100 (or 50 if you plan to only start at 50%, i.e. if(battery < flashLevel) FlashLed = 255 * battery / flashLevel + fastestFlash). Where flashLevel and fastestFlash might be user configurable. Always been told to avoid switches like the plague

Edit: Might need to subtract fastestFlash from the initial 255 if it doesn't simply interpret larger values as 255.

Edit: Also if battery only has ten or eleven states and we only do anything when the state has actually changed then I'd agree the switch statement for flashing, colour and rumble values (whichever are enabled) would be the least taxing on responsiveness. But whether a user should set all ten values or just a few depends on your user - for the vast majority I'd guess enable/disable, colour, fastestFlash, fastestRumble, threshold (when the effect happens) is more than enough.

(02-03-2014, 02:12 AM)HecticSeptic Wrote: [ -> ]From the code I'd say you might as well just calculate a value dynamically instead of have stages? Unless it impacts performance.

You could, for example, set it to 255 * battery / 100 (or 50 if you plan to only start at 50%, i.e. if(battery < flashLevel) FlashLed = 255 * battery / flashLevel + fastestFlash). Where flashLevel and fastestFlash might be user configurable. Always been told to avoid switches like the plague

Edit: Might need to subtract fastestFlash from the initial 255 if it doesn't simply interpret larger values as 255.

Take a look at how I did the Arthritis mode in the very latest commit. This is a high-performance way to do things: you do all your calculation when the variables change by filling out a table, and your 1:1 table mapping lookup is the fastest possible operation your computer can do. I'm trying hard to minimize latency, so this is a big consideration, yeah.

(02-02-2014, 03:52 PM)InhexSTER Wrote: [ -> ]Go to options in AC and make sure X360 Controller chosen, not Wireless Controller

I am using 1.2.1, and have confirmed it is set to xbox 360.