Re: Direction, and color
ok, so I lied. I keep making adjustments to how the color generation works, but to get the results I want.. i'm lost again. Currently, if I want to find red, I can get a factor for red where abs(sin((tCurAngle - tColorAngle) * pi / 180)) (cur angle is 0, color angle is also 0, factor returned is 0) Then do 255 - (255 * factor) so the value for red is 255. But for the other 2 colors, I need to return a factor of 1 so that they are completely removed so that the primary color is the only one left. To do this requires a current angle offset from the designated color angle to be 90 degrees. So for example, green is 60, to get a factor of 1, the current angle would have to be 150, and for blue it would have to be 30 on my imaginary, impossible number circle. I can fix this by setting my colors to 0, 90, 180. (again, only using half the circle) But doing it this way, I end up with grey between cycles, so there is a nice solid sequence of reds, then grey,then green, then grey, then blue, repeat. So, what I need to figure out, is a way to weight things, so that the closer 1 color gets to 255, then more reduction affect there is on the other 2 colors. Any suggestions? On Sun, Dec 14, 2014 at 2:47 PM, Mike Bonner bonnm...@gmail.com wrote: Last post on this, things are working well enough that I'm happy. In case anyone is interested, here is a link to a stack with 3 sliders, r, g, b sliders so that the weight of each color can be adjusted during cycling. All it does is change the background color of the card based on the sliders and cycling through (figmentary) angles. https://dl.dropboxusercontent.com/u/11957935/colorphase.livecode On Sat, Dec 13, 2014 at 8:45 PM, Mike Bonner bonnm...@gmail.com wrote: Oh, just realized, due to the normalization, I only needed to cycle 1 to 180 to get the full color chart. DOH. 360 repeats. (since its basically, seeing how far from a point on the circumference, based on degrees, 180 is the cap, and the abs() stuff makes dealing with negatives moot. ) On Sat, Dec 13, 2014 at 8:24 PM, Mike Bonner bonnm...@gmail.com wrote: Thanks for the ideas and hints, some ideas finally triggered in my noggin and I have a pretty good solution now. Craig, yeah I love the idea. A simple lookup table would work, especially since the motion of the objects is a simple x,y thing, so a keyed array would make it simple. I'm stubborn though, and want to generate a nice smooth transition (like my own home built color wheel algorithm.) The code (plus extra code that cycles the background color of a field just to see the visual) follows. -- constants for these. Mainly so that if I want skewed colors like heavy blue, I can tweak these. constant kRed=255,kGreen=255,kBlue=255 on mouseUp repeat with i = 1 to 360 -- morph the color based on degrees put i mod 360 into tCurAngle put round((colorshift(tCurAngle,0))* kRed) into tRed -- colorshift function does all the work. -- multiply the base color value by the factor returned from the colorshift function put round(( (colorshift(tCurAngle,240))) * kBlue ) into tBlue put round((colorshift(tCurAngle,120)) * kGreen) into tGreen set the backgroundcolor of field 3 to tRed,tGreen,tBlue wait 10 millisec with messages -- so you can more easily see the changes end repeat end mouseUp -- this is the heavy lifting. tcolorAngle is the angle that designates the stronges -- point of color intensity for that color. I've assigned, 0, 120, 240 function colorshift tCurAngle, tColorAngle -- subtract tColorangle to normalize -- then convert that angle to radians, which gives a factor between 0 and 1 -- which will then be used to adjust the color value itself put abs(sin((tCurAngle - tColorAngle) * pi / 180)) into tAdjustedAngle return tAdjustedAngle end colorshift From there, it should be easy to adjust by velocity. If initial values are maxed at 200, that gives a 55 point per color scale that can be used for intensity adjustments, which could be another factor multiplied uniformly across all 3 rgb values. I'm sure it can be simplified and cleaned up, but is working pretty well. Thanks all for helping me get my head wrapped around this. On Sat, Dec 13, 2014 at 12:32 AM, Mike Bonner bonnm...@gmail.com wrote: Hey! Simple and easy, Thanks much, will try and get it working tomorrow. On Fri, Dec 12, 2014 at 11:27 AM, Richmond richmondmathew...@gmail.com wrote: On 12/12/14 19:19, Mike Bonner wrote: I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect
Re: Direction, and color
On 15/12/14 17:47, Mike Bonner wrote: ok, so I lied. I keep making adjustments to how the color generation works, but to get the results I want.. i'm lost again. Currently, if I want to find red, I can get a factor for red where abs(sin((tCurAngle - tColorAngle) * pi / 180)) (cur angle is 0, color angle is also 0, factor returned is 0) Then do 255 - (255 * factor) so the value for red is 255. But for the other 2 colors, I need to return a factor of 1 so that they are completely removed so that the primary color is the only one left. To do this requires a current angle offset from the designated color angle to be 90 degrees. So for example, green is 60, to get a factor of 1, the current angle would have to be 150, and for blue it would have to be 30 on my imaginary, impossible number circle. I can fix this by setting my colors to 0, 90, 180. (again, only using half the circle) But doing it this way, I end up with grey between cycles, so there is a nice solid sequence of reds, then grey,then green, then grey, then blue, repeat. So, what I need to figure out, is a way to weight things, so that the closer 1 color gets to 255, then more reduction affect there is on the other 2 colors. Any suggestions? I must be quite stupid as I don't understand what you are trying to convey. How about moving this discussion to the Forums with some pretty pictures? Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
So, I had a go at this. Here’s my test stack: go url http://colin.scienceninja.com/colorwheel.livecode” Choose the browse tool and click the button. The script deletes any existing graphics and then makes 315 new graphics, with the forelock set to a calculated amount. There’s one difference from what was asked for, because angles start from the east, not from the north. In my example red is to the right, blue is lower left, and green upper left. Like, 3, 7, and 11 if it was a clock. I suspect I have something reversed, I wanted green to be where blue is. But still, it’ll show off the idea. Here’s the button script, take a look at it for a while, and the stack, then ask questions! on mouseUp lock screen repeat while the number of graphics 0 delete graphic 1 end repeat repeat with a = 1 to 315 new graphic set the width of graphic a to 10 set the height of graphic a to 10 put (a-1)/50 into ang put cos(ang) * 200 into dx put sin(ang) * 200 into dy set the loc of graphic a to 300 + dx,300+dy set the forecolor of graphic a to getred(ang),getgreen(ang),getblue(ang) if a = 1 then put the forecolor of graphic a end repeat unlock screen end mouseUp function getred val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end getred function getgreen val add 2/3*PI to val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end getgreen function getblue val add 4/3*PI to val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end getblue ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
By the way, I copied my v7 script a 6.6.4 stack, so that the stack can open in more versions. On Dec 15, 2014, at 10:02 PM, Colin Holgate co...@verizon.net wrote: go url http://colin.scienceninja.com/colorwheel.livecode http://colin.scienceninja.com/colorwheel.livecode” ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Figured out the reason blue and green were reverse, I should have done a subtraction not an addition. I replaced the stack. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Thank you SO much. Will start at it for a few days to see if I can wrap my noggin around it. On Mon, Dec 15, 2014 at 8:12 PM, Colin Holgate co...@verizon.net wrote: Figured out the reason blue and green were reverse, I should have done a subtraction not an addition. I replaced the stack. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Ah k. This method gets rid of any and all tri-color blends, simplifying things, at which point it becomes easy. Another method to do the same thing (or maybe the same method, but in a way I have a chance of understanding) is to determine if an angle falls between say, red and green, find the ratio of the distances to each, and use that as a factor of 255 to create the color. So if red is 90, green is 210, and the angle is 150, (the midway point) the red factor would be .5, green would be .5, so we'd end up with 127,127,0 An angle of 110 would be 42,212,0 (the green factor being .83, the red factor being .17) Easy then to do as Richmond said, and make a lookup table since its simply 2 inverse linear values anyway. Eliminating the 3rd color as part of the blend makes it SO much easier. Going to stare at your code and research till I actually understand it. At which point I will change it in silly and idiotic ways to see what happens. On Mon, Dec 15, 2014 at 8:17 PM, Mike Bonner bonnm...@gmail.com wrote: Thank you SO much. Will start at it for a few days to see if I can wrap my noggin around it. On Mon, Dec 15, 2014 at 8:12 PM, Colin Holgate co...@verizon.net wrote: Figured out the reason blue and green were reverse, I should have done a subtraction not an addition. I replaced the stack. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
On Dec 15, 2014, at 11:07 PM, Mike Bonner bonnm...@gmail.com wrote: I have a chance of understanding) is to determine if an angle falls between say, red and green, find the ratio of the distances to each, and use that as a factor of 255 to create the color. That is exactly what my code is doing. There are several numbers in the code that help cheat towards an easy solution. I’ll talk through a few of those lines: repeat with a = 1 to 315 new graphic set the width of graphic a to 10 set the height of graphic a to 10 put (a-1)/50 into ang This just gives PI * 100 (roughly) objects spread over a 2*PI range, to draw the circle of graphics. function getred val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end getred 120 degrees is 2/3PI. I take the angle we’re at and make it be in the range of -PI to +PI, and then take the absolute value of that. I subtract the angle from 2/3*PI, to find out how far from zero we are. If it’s more than 120 degrees, the max(0, takes care of it. The divide by 2/3*PI makes the results be in the range 0-1, which gets multiplied by 255. function getgreen val subtract 2/3*PI from val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end get green I just add 2/3* PI or 4/3*PI to offset the green and blue angles, so that the math becomes just the same as it was for red. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Holy crap, I think I get it. On Mon, Dec 15, 2014 at 9:18 PM, Colin Holgate co...@verizon.net wrote: On Dec 15, 2014, at 11:07 PM, Mike Bonner bonnm...@gmail.com wrote: I have a chance of understanding) is to determine if an angle falls between say, red and green, find the ratio of the distances to each, and use that as a factor of 255 to create the color. That is exactly what my code is doing. There are several numbers in the code that help cheat towards an easy solution. I’ll talk through a few of those lines: repeat with a = 1 to 315 new graphic set the width of graphic a to 10 set the height of graphic a to 10 put (a-1)/50 into ang This just gives PI * 100 (roughly) objects spread over a 2*PI range, to draw the circle of graphics. function getred val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end getred 120 degrees is 2/3PI. I take the angle we’re at and make it be in the range of -PI to +PI, and then take the absolute value of that. I subtract the angle from 2/3*PI, to find out how far from zero we are. If it’s more than 120 degrees, the max(0, takes care of it. The divide by 2/3*PI makes the results be in the range 0-1, which gets multiplied by 255. function getgreen val subtract 2/3*PI from val if val PI then put 2*PI - val into val put abs(val) into val return round(max(0,(2/3*Pi - val)/(2/3*PI)) * 255) end get green I just add 2/3* PI or 4/3*PI to offset the green and blue angles, so that the math becomes just the same as it was for red. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Thanks for the ideas and hints, some ideas finally triggered in my noggin and I have a pretty good solution now. Craig, yeah I love the idea. A simple lookup table would work, especially since the motion of the objects is a simple x,y thing, so a keyed array would make it simple. I'm stubborn though, and want to generate a nice smooth transition (like my own home built color wheel algorithm.) The code (plus extra code that cycles the background color of a field just to see the visual) follows. -- constants for these. Mainly so that if I want skewed colors like heavy blue, I can tweak these. constant kRed=255,kGreen=255,kBlue=255 on mouseUp repeat with i = 1 to 360 -- morph the color based on degrees put i mod 360 into tCurAngle put round((colorshift(tCurAngle,0))* kRed) into tRed -- colorshift function does all the work. -- multiply the base color value by the factor returned from the colorshift function put round(( (colorshift(tCurAngle,240))) * kBlue ) into tBlue put round((colorshift(tCurAngle,120)) * kGreen) into tGreen set the backgroundcolor of field 3 to tRed,tGreen,tBlue wait 10 millisec with messages -- so you can more easily see the changes end repeat end mouseUp -- this is the heavy lifting. tcolorAngle is the angle that designates the stronges -- point of color intensity for that color. I've assigned, 0, 120, 240 function colorshift tCurAngle, tColorAngle -- subtract tColorangle to normalize -- then convert that angle to radians, which gives a factor between 0 and 1 -- which will then be used to adjust the color value itself put abs(sin((tCurAngle - tColorAngle) * pi / 180)) into tAdjustedAngle return tAdjustedAngle end colorshift From there, it should be easy to adjust by velocity. If initial values are maxed at 200, that gives a 55 point per color scale that can be used for intensity adjustments, which could be another factor multiplied uniformly across all 3 rgb values. I'm sure it can be simplified and cleaned up, but is working pretty well. Thanks all for helping me get my head wrapped around this. On Sat, Dec 13, 2014 at 12:32 AM, Mike Bonner bonnm...@gmail.com wrote: Hey! Simple and easy, Thanks much, will try and get it working tomorrow. On Fri, Dec 12, 2014 at 11:27 AM, Richmond richmondmathew...@gmail.com wrote: On 12/12/14 19:19, Mike Bonner wrote: I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect color, and speed would affect the end color based on a gradient dark to light. I hope the explanation is clearer than mud. Any suggestions, or reading material that might help get me kickstarted? TIA Mike ___ I don't think that should be unduly difficult . . . For instance, one could leverage RGB codes so that, let us say, the direction in degrees could be signalled something like this: RRR= round (255/(360-DIR) set the backgroundColor of grc myFatBlob to RRR,GGG,BBB where DIR is the direction in degrees, GGG is some number 0GGG256, and so is BBB. Darkness could be worked out by having one's Blobs consist of a pair of graphics (one on top of the other) where the lower one is black. Speed could then be signalled by setting the BLEND level of the top one. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Oh, just realized, due to the normalization, I only needed to cycle 1 to 180 to get the full color chart. DOH. 360 repeats. (since its basically, seeing how far from a point on the circumference, based on degrees, 180 is the cap, and the abs() stuff makes dealing with negatives moot. ) On Sat, Dec 13, 2014 at 8:24 PM, Mike Bonner bonnm...@gmail.com wrote: Thanks for the ideas and hints, some ideas finally triggered in my noggin and I have a pretty good solution now. Craig, yeah I love the idea. A simple lookup table would work, especially since the motion of the objects is a simple x,y thing, so a keyed array would make it simple. I'm stubborn though, and want to generate a nice smooth transition (like my own home built color wheel algorithm.) The code (plus extra code that cycles the background color of a field just to see the visual) follows. -- constants for these. Mainly so that if I want skewed colors like heavy blue, I can tweak these. constant kRed=255,kGreen=255,kBlue=255 on mouseUp repeat with i = 1 to 360 -- morph the color based on degrees put i mod 360 into tCurAngle put round((colorshift(tCurAngle,0))* kRed) into tRed -- colorshift function does all the work. -- multiply the base color value by the factor returned from the colorshift function put round(( (colorshift(tCurAngle,240))) * kBlue ) into tBlue put round((colorshift(tCurAngle,120)) * kGreen) into tGreen set the backgroundcolor of field 3 to tRed,tGreen,tBlue wait 10 millisec with messages -- so you can more easily see the changes end repeat end mouseUp -- this is the heavy lifting. tcolorAngle is the angle that designates the stronges -- point of color intensity for that color. I've assigned, 0, 120, 240 function colorshift tCurAngle, tColorAngle -- subtract tColorangle to normalize -- then convert that angle to radians, which gives a factor between 0 and 1 -- which will then be used to adjust the color value itself put abs(sin((tCurAngle - tColorAngle) * pi / 180)) into tAdjustedAngle return tAdjustedAngle end colorshift From there, it should be easy to adjust by velocity. If initial values are maxed at 200, that gives a 55 point per color scale that can be used for intensity adjustments, which could be another factor multiplied uniformly across all 3 rgb values. I'm sure it can be simplified and cleaned up, but is working pretty well. Thanks all for helping me get my head wrapped around this. On Sat, Dec 13, 2014 at 12:32 AM, Mike Bonner bonnm...@gmail.com wrote: Hey! Simple and easy, Thanks much, will try and get it working tomorrow. On Fri, Dec 12, 2014 at 11:27 AM, Richmond richmondmathew...@gmail.com wrote: On 12/12/14 19:19, Mike Bonner wrote: I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect color, and speed would affect the end color based on a gradient dark to light. I hope the explanation is clearer than mud. Any suggestions, or reading material that might help get me kickstarted? TIA Mike ___ I don't think that should be unduly difficult . . . For instance, one could leverage RGB codes so that, let us say, the direction in degrees could be signalled something like this: RRR= round (255/(360-DIR) set the backgroundColor of grc myFatBlob to RRR,GGG,BBB where DIR is the direction in degrees, GGG is some number 0GGG256, and so is BBB. Darkness could be worked out by having one's Blobs consist of a pair of graphics (one on top of the other) where the lower one is black. Speed could then be signalled by setting the BLEND level of the top one. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
On 12/12/14 19:19, Mike Bonner wrote: I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect color, and speed would affect the end color based on a gradient dark to light. I hope the explanation is clearer than mud. Any suggestions, or reading material that might help get me kickstarted? TIA Mike ___ I don't think that should be unduly difficult . . . For instance, one could leverage RGB codes so that, let us say, the direction in degrees could be signalled something like this: RRR= round (255/(360-DIR) set the backgroundColor of grc myFatBlob to RRR,GGG,BBB where DIR is the direction in degrees, GGG is some number 0GGG256, and so is BBB. Darkness could be worked out by having one's Blobs consist of a pair of graphics (one on top of the other) where the lower one is black. Speed could then be signalled by setting the BLEND level of the top one. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Mike. If you know the direction, either because you set it up that way or you interrogate the x,y position regularly, can't you set your colors based on that information? Same with the speed? Craig -Original Message- From: Mike Bonner bonnm...@gmail.com To: How to use LiveCode use-livecode@lists.runrev.com Sent: Fri, Dec 12, 2014 12:20 pm Subject: Direction, and color I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect color, and speed would affect the end color based on a gradient dark to light. I hope the explanation is clearer than mud. Any suggestions, or reading material that might help get me kickstarted? TIA Mike ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Direction, and color
Hey! Simple and easy, Thanks much, will try and get it working tomorrow. On Fri, Dec 12, 2014 at 11:27 AM, Richmond richmondmathew...@gmail.com wrote: On 12/12/14 19:19, Mike Bonner wrote: I have a quick question, its one of those that should be obvious, but i'm just not seeing it. What i'm playing with right now, is just a bunch of round grc moving on screen. (an adaption of the swarm sample stack created by scott rossi) What I'd like to do, is modify the colors of of each ball based on direction and speed. Sort of like a color wheel, zero speed or direction being the center of the wheel. So, direction would affect color, and speed would affect the end color based on a gradient dark to light. I hope the explanation is clearer than mud. Any suggestions, or reading material that might help get me kickstarted? TIA Mike ___ I don't think that should be unduly difficult . . . For instance, one could leverage RGB codes so that, let us say, the direction in degrees could be signalled something like this: RRR= round (255/(360-DIR) set the backgroundColor of grc myFatBlob to RRR,GGG,BBB where DIR is the direction in degrees, GGG is some number 0GGG256, and so is BBB. Darkness could be worked out by having one's Blobs consist of a pair of graphics (one on top of the other) where the lower one is black. Speed could then be signalled by setting the BLEND level of the top one. Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
