|
Post by dgustavus on Oct 5, 2014 6:48:16 GMT -8
I am using my gameduino2 as a "console" for my robot. I want to input motor speed values using vertical sliders, but I want the tracking value to increase going from the bottom up rather than top down. In the vertical orientation, is there a way to place the zero value at the bottom rather than the top?
Thanks, Duane
|
|
|
Post by jamesbowman on Oct 5, 2014 6:59:04 GMT -8
Hmm, difficult. The hardware tracker (cmd_track) always assumes zero is at the top of the tracking scale. Is it possible for you to invert the tracking value in software?
|
|
|
Post by dgustavus on Oct 5, 2014 8:44:02 GMT -8
Thanks for the quick reply! I already tried that, and yes the value can be inverted by subtracting from 65535, but the slider follows the cmd_track value. I connected the modified value to a gauge, and it looks good but the slider doesn't (ie they move in opposite directions). What I need is a widget to set variables (like desired speed). Left to right will work, of course, but it is not a natural as low to high for increasing numbers. Also, is there a toggle that is bistable (ie only on or off). I am using button widgets, but the "bounce" make them a little difficult to control.
Thanks again, Duane
|
|
|
Post by jamesbowman on Oct 7, 2014 11:01:14 GMT -8
OK, so to have the slider be inverted, you can change the drawing code from:
GD.cmd_slider(16, 199, 104, 10, options, value, 65535); to:
GD.cmd_slider(16, 199, 104, 10, options, value, 65535 - value); For a toggle, you can make it bistable using:
GD.cmd_toggle(360, 62, 80, 29, options, value ? 0 : 65535, "that" "\xff" "this"); For debounce, this kind of pattern seems to work quite well:
static byte prevkey;
void loop() { GD.get_inputs(); byte key = GD.inputs.tag; prevkey = key; if (prevkey == 0) { if (key == 100) etc. } }
prevkey tracks the previous touch input, and the code only reacts to the current touch if there was no touch on the last cycle.
|
|
|
Post by dgustavus on Oct 7, 2014 17:16:06 GMT -8
Thanks for the hints. I was unable to get the slider to work with that idea. I could get the values shown by the slider button to move from low to high with the slider button tracking correctly, but only when the actual motion of my finger was from high to low! I have switched them back to horizontal in the interface. The debouncing hint was very useful as it was simpler than my version and seems to work better. With that approach, I can simply use rectangles with tags, and get a very nice "radio button" which changes colors to indicate status. I had very little luck making cmd_bgcolor do anything I could understand with widgets. A quick note, which you are no doubt already aware of, is that the pdf book I got as part of the kickstarter reward says the GD.input.tag is 255 when there is not touch, instead of 0.
Thanks much for the help! Duane
|
|
|
Post by jamesbowman on Oct 7, 2014 17:58:51 GMT -8
OK - if you have some code snippets for the non-working things... be good to take a look.
Btw cmd_bgcolor() only changes the background color of the widgets... cmd_fgcolor() sets the color of the foreground color, which is used for the knobs and sliders:
GD.cmd_fgcolor(0x00ff00); // draw knobs bright green
|
|
|
Post by dgustavus on Oct 14, 2014 6:30:10 GMT -8
Hi James, Sorry for the delay in replying. I have resolved the sliders issue by simply using the sliders in horizontal orientation. Your example above which changes the range value does not work as the slider passes the midpoint (range becomes smaller than the value), and setting the value by subtracting it from 65535 does work in terms of the display of the slider button, but the finger press must still be from high to low to generate the increasing value. I think the library would have to be modified to make a vertical slider with values that increase as the motion goes up.
I am using NilRTOS to do the GDswap() every 50 ms, which gives a fluid display rate, does a good job of "debouncing" and also conserves lots of cycles to communicate with the main processor (I am using the GD2 as a console device on a robot). Probably not fast enough for a game, but works good for a bunch of switches and gauges.
Cheers, Duane
|
|