Re: Adventures in Rotation
Bill Marriott wrote: Ok, as our regular viewers know, I'm trying to mimic with Rev a pretty little clock distributed with Konfabulator. The way K. does this clock is to create little PNGs for each of the elements (second hand, minute hand, rim, background), package them up in XML, and animate (rotate) them in JavaScript. Attempt 4 (revised): revRotatePoly an irregular polygon So, I drew myself a pretty minute hand and then wrote a script. Code used: on mouseUp repeat with i = 1 to 360 revRotatePoly the long ID of graphic minuteHand,1 wait for 50 milliseconds end repeat end mouseUp (I know the wait for method was not what I was going to use in my eventual stack, for performance reasons, but I just wanted to test out spinning it.) Well, running this script was a shocker. It had the effect of crumpling my pretty minute hand into a little ball. If you'd like to see what happens, go to revOnline under my space, MerryOtter -- the stack is, Fun with revRotatePoly I rather like that effect - though it certainly shouldn't be called rotate :-) My clock hand *is* pretty fancy, it's got 56 points. But the same thing happens with graphics of only 3 points. Open the stack and try the simplest kind of clock hand you could imagine with snip #13) General flakiness. I would definitely say revCrumplePoly is a better name for the revRotatePoly command. Is there any situation where revRotatePoly could be useful? Not if it does this. Totally bugged. (I suspect the reason why is that Rev doesn't have fractional coordinates? Could such a limitation really result in such dramatic distortion? If this is the case, then Rev should store fractionals, but render to integers.) I think your suspicion is entirely correct. I think it would be generally very helpful if Rev would allow non-integer co-ords in the points list, and simply round to integers before drawing. I change the code to put the points of grc minuteHand into tPoints repeat with i = 1 to 360 set the lockScreen to true set the points of grc minuteHand to tPoints revRotatePoly the long ID of graphic minuteHand, i-- note the change from 1 to i here set the lockScreen to false set the thumbposition of scrollbar spinProgress to i wait for 50 milliseconds end repeat and it now does what it's intended to do. Though I really dislike what it's intended to do - rotate the object, then translate it so as to keep the top left of the bounding rectangle of the rotated shape the same. We had a thread on rotating polygons back in March (to save you cracking out the trig books), here is the code modified to use the rotate handler I suggested then. Note this is written to emphasize readability rather than performance - could probably be made faster if needed. on mouseUp put the points of grc minuteHand into tPoints repeat with i = 1 to 360 set the lockScreen to true set the points of grc minuteHand to tPoints myRotatePoly the name of grc minuteHand, i, 0, 24 -- revRotatePoly the long ID of graphic minuteHand, i set the lockScreen to false set the thumbposition of scrollbar spinProgress to i wait for 50 milliseconds with messages end repeat set the points of grc minuteHand to tPoints end mouseUp on myRotatePoly pGraphic, pAngle, basex, basey put the topLeft of pGraphic into tTopLeft put myPoints(pGraphic, basex, basey) into tPoints-- returns the list of points, relative to the base point put the loc of pGraphic into tLoc put sin(pAngle * (pi / 180)) into tSinAngle put cos(pAngle * (pi / 180)) into tCosAngle put (number of items of tPoints) div 2 into tNumItems repeat with i = 1 to tNumItems put (item (i + (i - 1)) of tPoints) into tCurrentH -- + item 1 of the center put (item (i + i) of tPoints) into tCurrentV -- + item 2 of the center put trunc((tCosAngle * tCurrentH) - (tSinAngle * tCurrentV)) into tTempH put trunc((tSinAngle * tCurrentH) + (tCosAngle * tCurrentV)) into tTempV put tTempH + basex into tCurrentH -- and add back the base x and y put tTempV + basey into tCurrentV put tCurrentH,tCurrentV comma after tFinalPoints end repeat delete last char of tFinalPoints set the points of pGraphic to tFinalPoints end myRotatePoly function myPoints pGraphic, basex, basey put the number of lines in the points of pGraphic into tNumPoints put empty into tResult put the points of pGraphic into tPoints put basex into tStartlH put basey into tStartV replace cr with comma in tPoints if last char of tPoints is comma then delete last char of tPoints repeat with i = 1 to tNumPoints put (item (i + (i - 1)) of tPoints) - tStartlH into tCurrentH put (item (i + i) of tPoints) - tStartV into tCurrentV put tCurrentH,tCurrentV comma after
Re: Adventures in Rotation
Hi Bill, Many developers had published handlers for rotating vector poligonal graphics. You could find handlers to rotate vector polygonal graphic using arrays in my website: http://www.geocities.com/capellan2000/graphics_transformations_01.zip These functions are included too in the BETA stack penTool v0.3.2.d http://aulasdigitales.net/penToolv032d.zip You are right, about keeping the fractional numbers while rotating, moving fliping, skewing or scaling vector graphics. in the BETA stack penTool, i use custom properties in the vector graphic to store this information. Look for the custom properties named bPoints and cPoints. Have a nice day! al Visit my site: http://www.geocities.com/capellan2000/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Adventures in Rotation
Message: 7 Date: Sun, 4 Dec 2005 19:16:29 -0500 From: Bill Marriott [EMAIL PROTECTED] Subject: Adventures in Rotation To: use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] #13) General flakiness. I would definitely say revCrumplePoly is a better name for the revRotatePoly command. Is there any situation where revRotatePoly could be useful? Not if it does this. Totally bugged. (I suspect the reason why is that Rev doesn't have fractional coordinates? Could such a limitation really result in such dramatic distortion? If this is the case, then Rev should store fractionals, but render to integers.) Here, here. I have been promoting fractional coordinates for graphic points for some time. Try the following handler: on mouseUp set the loc of me to 200.6,200.4 put the loc of me into msg box--reveals 200,200 set the points of grc 1 to 100,100 cr 200.4,200.6 --There is no evidence of the line graphic -- The fractional point is not truncated but interpreted as a blank line. end mouseUp RR will accept fractional coordinates for controls (it truncates the coordinates) but it will not accept fractional graphic points. You don't get an error message and no feedback that the problem lines in the fractional coordinates. Problems arises when the graphic points are computed; the programmer may not realize that the points are fractional or that RR will not accept fractional points. Any point with a fractional coordinate is interpreted as an empty point and therefore a discontinuity. It has been a while and I forget the details, but I think there was support for this change in RR; so far no implementation. Jim ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Adventures in Rotation
While I agree that it would be handy if the engine could accept non- integers for graphic points, a simple function to round a list of 4000 or so points to integers took 34 milliseconds on my 1.5Ghz PB G4...hardly onerous in either execution time or coding effort. Cheers, Mark On 5 Dec 2005, at 02:07, Jim Hurley wrote: Message: 7 Date: Sun, 4 Dec 2005 19:16:29 -0500 From: Bill Marriott [EMAIL PROTECTED] Subject: Adventures in Rotation To: use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] #13) General flakiness. I would definitely say revCrumplePoly is a better name for the revRotatePoly command. Is there any situation where revRotatePoly could be useful? Not if it does this. Totally bugged. (I suspect the reason why is that Rev doesn't have fractional coordinates? Could such a limitation really result in such dramatic distortion? If this is the case, then Rev should store fractionals, but render to integers.) Here, here. I have been promoting fractional coordinates for graphic points for some time. Try the following handler: on mouseUp set the loc of me to 200.6,200.4 put the loc of me into msg box--reveals 200,200 set the points of grc 1 to 100,100 cr 200.4,200.6 --There is no evidence of the line graphic -- The fractional point is not truncated but interpreted as a blank line. end mouseUp RR will accept fractional coordinates for controls (it truncates the coordinates) but it will not accept fractional graphic points. You don't get an error message and no feedback that the problem lines in the fractional coordinates. Problems arises when the graphic points are computed; the programmer may not realize that the points are fractional or that RR will not accept fractional points. Any point with a fractional coordinate is interpreted as an empty point and therefore a discontinuity. It has been a while and I forget the details, but I think there was support for this change in RR; so far no implementation. Jim ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Adventures in Rotation
Bill Marriott wrote: Now I thought ... hey what about using a graphic? That is what Revolution calls objects created with its built-in tools for simple vector objects. I'll use one of those. Attempt 3: rotate a rectangle snip failures You need to set the points of the graphic. The most amazing things can be done with graphics with this method. Geoff Canyon, of this list, made a whole animated shoot-out game using a *single* graphic. You really should go look up the clock threads in the archives. It's a common project. Someone sent me a clock they made a couple of years ago that was just gorgous, doing exactly what you describe. I can't share it, as it isn't mine and it was a private exchange. If he's still on the list, maybe he'll respond. Look at some of these in the mean time, there are probably some pointers: http://search.gmane.org/?query=clock+scriptgroup=gmane.comp.ide.revolution.user -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Adventures in Rotation
Mark, It's not hard to round to integers. The problem is that Rev works with integers for its rotation algorithm and therefore corrupts the graphic in the process. Bill Mark Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While I agree that it would be handy if the engine could accept non- integers for graphic points, a simple function to round a list of 4000 or so points to integers took 34 milliseconds on my 1.5Ghz PB G4...hardly onerous in either execution time or coding effort. Cheers, Mark On 5 Dec 2005, at 02:07, Jim Hurley wrote: Message: 7 Date: Sun, 4 Dec 2005 19:16:29 -0500 From: Bill Marriott [EMAIL PROTECTED] Subject: Adventures in Rotation To: use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] #13) General flakiness. I would definitely say revCrumplePoly is a better name for the revRotatePoly command. Is there any situation where revRotatePoly could be useful? Not if it does this. Totally bugged. (I suspect the reason why is that Rev doesn't have fractional coordinates? Could such a limitation really result in such dramatic distortion? If this is the case, then Rev should store fractionals, but render to integers.) Here, here. I have been promoting fractional coordinates for graphic points for some time. Try the following handler: on mouseUp set the loc of me to 200.6,200.4 put the loc of me into msg box--reveals 200,200 set the points of grc 1 to 100,100 cr 200.4,200.6 --There is no evidence of the line graphic -- The fractional point is not truncated but interpreted as a blank line. end mouseUp RR will accept fractional coordinates for controls (it truncates the coordinates) but it will not accept fractional graphic points. You don't get an error message and no feedback that the problem lines in the fractional coordinates. Problems arises when the graphic points are computed; the programmer may not realize that the points are fractional or that RR will not accept fractional points. Any point with a fractional coordinate is interpreted as an empty point and therefore a discontinuity. It has been a while and I forget the details, but I think there was support for this change in RR; so far no implementation. Jim ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Adventures in Rotation
Apologies...didn't follow the whole thread. Mark On 5 Dec 2005, at 04:17, Bill Marriott wrote: Mark, It's not hard to round to integers. The problem is that Rev works with integers for its rotation algorithm and therefore corrupts the graphic in the process. Bill Mark Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While I agree that it would be handy if the engine could accept non- integers for graphic points, a simple function to round a list of 4000 or so points to integers took 34 milliseconds on my 1.5Ghz PB G4...hardly onerous in either execution time or coding effort. Cheers, Mark On 5 Dec 2005, at 02:07, Jim Hurley wrote: Message: 7 Date: Sun, 4 Dec 2005 19:16:29 -0500 From: Bill Marriott [EMAIL PROTECTED] Subject: Adventures in Rotation To: use-revolution@lists.runrev.com Message-ID: [EMAIL PROTECTED] #13) General flakiness. I would definitely say revCrumplePoly is a better name for the revRotatePoly command. Is there any situation where revRotatePoly could be useful? Not if it does this. Totally bugged. (I suspect the reason why is that Rev doesn't have fractional coordinates? Could such a limitation really result in such dramatic distortion? If this is the case, then Rev should store fractionals, but render to integers.) Here, here. I have been promoting fractional coordinates for graphic points for some time. Try the following handler: on mouseUp set the loc of me to 200.6,200.4 put the loc of me into msg box--reveals 200,200 set the points of grc 1 to 100,100 cr 200.4,200.6 --There is no evidence of the line graphic -- The fractional point is not truncated but interpreted as a blank line. end mouseUp RR will accept fractional coordinates for controls (it truncates the coordinates) but it will not accept fractional graphic points. You don't get an error message and no feedback that the problem lines in the fractional coordinates. Problems arises when the graphic points are computed; the programmer may not realize that the points are fractional or that RR will not accept fractional points. Any point with a fractional coordinate is interpreted as an empty point and therefore a discontinuity. It has been a while and I forget the details, but I think there was support for this change in RR; so far no implementation. Jim ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
